¿Puede Silicon Secured Memory evitar sobrecargas de búfer?

  

¿El SSM puede prevenir de manera confiable desbordamientos de búfer?

No pretende ofrecer un 100% de prevención, pero definitivamente ofrece una protección más granular en comparación con la solución anterior basada en hardware (que generalmente tenía granularidad de página) y un rendimiento mucho mejor que las protecciones basadas en software con una granularidad similar. Hay algunas limitaciones como

• Tu código tiene que utilizarlo realmente. Esto puede ser tan simple como usar el malloc provisto, pero es necesario cambiar las asignaciones de memoria personalizadas como las que se hacen en OpenSSL. Y no sé si el compilador también agregará dicha protección a la pila o si esto solo es posible para los datos asignados en el montón.
• La memoria debe estar alineada a 64 bytes. Por lo tanto, no detectará cuando se desborda una asignación de solo 32 bytes.
• Solo hay 16 colores (4 bits) disponibles para cada región de 64 bytes. Por lo tanto, la posibilidad de que algún puntero aleatorio tenga el mismo color que la región de memoria protegida sigue siendo del 6%.

Por lo tanto, no es perfecto, pero la posibilidad de detectar problemas en forma temprana y, por lo tanto, evitar ataques es mucho mayor que con las soluciones existentes, al menos con soluciones en la misma clase de rendimiento.

  

intentos anteriores para resolver los desbordamientos de búfer (por ejemplo, DEP)

En mi opinión, DEP no protege en absoluto contra el exceso de búfer, sino que solo se asegura de que no se pueda ejecutar simplemente el código que se escribió en la pila o el montón. Por lo tanto, solo trata algunas de las formas posibles de hacer uso de un desbordamiento de búfer exitoso, mientras que SSM puede ayudar a prevenir el desbordamiento en sí mismo.

Como complemento de los puntos que ya he hecho en la otra respuesta, señalaré dos inquietudes adicionales, señaladas en este elemento de The Register :

Primero: Incluso si el código de un atacante adivina incorrectamente el "color" que necesita usar en su puntero malicioso (y la posibilidad de 1 en 16 de hacerlo bien no es muy trivial, al menos en este contexto) y la excepción del el procesador hace que la aplicación en cuestión se bloquee, lo que probablemente no será lo suficientemente bueno en muchos casos. El objetivo necesitará un software de seguridad o de supervisión de registros para (a) ver que se ha producido el bloqueo & reconozca la causa especial de la misma y (b) al menos haga sonar la alerta a los administradores sobre el ataque. (Por supuesto, preferiblemente se instalaría un sofisticado IDPS basado en host en los servidores del objetivo, capaz de reconocer el código de explotación que desencadenó la excepción y tomar contramedidas automáticas para evitar que se ejecute nuevamente en futuros ataques. Preferiblemente ...)

Si, por otro lado, los bloqueos de la aplicación pasan desapercibidos y las instancias bloqueadas simplemente vuelven a crear instancias suficientes las veces que el código del atacante tendrá esa posibilidad de 1 en 16 de igualar el color del bloque de memoria de 64 bits quiere cargar Sin pasar por esta línea de defensa. En otras palabras, si no presta atención a lo que hacen sus aplicaciones y servidores, es muy probable que se queme. (Sí, duh.)

Segundo: Si un atacante puede encontrar alguna forma de discernir cuál es el color del bloque de memoria específico que desea cargar, el atacante puede ( puede ) simplemente poder simplemente establece el puntero a ese color . ¿Cuán vulnerable a los ataques en este sentido es probable que sea la nueva protección? Bueno, para comenzar a responder, es probable que se requieran más detalles técnicos que los que parecen estar disponibles hasta ahora sobre cómo va a funcionar todo esto. (Más un contestador que sabe mucho, mucho, mucho, mucho más sobre SPARC que yo).

Incluso con las preocupaciones / limitaciones anteriores, sin embargo, es una medida de seguridad realmente interesante basada en hardware que parece más ambiciosa que lo que los fabricantes de silicio otras arquitecturas (tos ... Intel ... ARM ... tos ) estamos tratando de hacer para mejorar la protección de la memoria en este momento. (Incluso si el concepto general de tener claves de protección / verificación de información para bloques de memoria no es nuevo). Realmente será bastante interesante ver cuánta diferencia real y positiva en la protección de exploits (si existe) hace que esto sea para las tiendas Oracle. .