No quiero escribir sobre Spectre, pero tengo que hacerlo: la semana pasada esta es, con mucho, la noticia más importante. Los representantes de la comunidad académica mostraron las nuevas opciones de vulnerabilidad de Spectre, así como las originales. Un investigador del Instituto de Tecnología de Massachusetts Vladimir Kiryansky y el experto independiente Karl Waldspurger mostraron dos nuevas modificaciones a Spectre, llamadas Spectre 1.1 y Spectre 1.2 (
novedad ,
trabajo científico original), sin logotipos ni logotipos.
Las diferencias importantes con respecto a la vulnerabilidad Spectre original en ambos casos son el uso de un mecanismo de grabación especulativo. En el caso de Specter 1.1, un ataque teóricamente le permite causar desbordamientos de búfer (también especulativos) y leer la sección de memoria "prohibida". Specter 1.2 proporciona la capacidad de sobrescribir información de solo lectura y, en teoría, permite que un ataque de escape de sanbox evite los sistemas de protección de hardware. Para el descubrimiento de la vulnerabilidad, los investigadores recibieron cien mil dólares como parte del programa de eliminación de errores de Intel, y hoy es uno de los pagos más grandes. Las vulnerabilidades se ven afectadas por los procesadores Intel, ARM y, probablemente, los procesadores AMD.
Según los autores, uno de los hallazgos clave del estudio es precisamente el nuevo concepto de "desbordamiento de buffer especulativo". Un desbordamiento provoca una operación de escritura: realizada en el momento correcto y en el lugar correcto, inevitablemente se descartará como incorrecta, pero incluso antes de eso abre la posibilidad de leer un área de memoria a la que el proceso de ataque no debería tener acceso.
Una ilustración clave de la idea: la verificación de límites no está utilizando una operación de lectura, como en el espectro original, sino con una operación de escritura.La lista de condiciones bajo las cuales se puede implementar una de las nuevas vulnerabilidades en la práctica ocupa casi más espacio que una descripción del mecanismo de ataque. Esta es la complejidad de las vulnerabilidades de hardware de esta clase: demasiado debe coincidir para que el ataque tenga éxito. Pero cuando ocurre un ataque, en el peor de los casos, le permite robar información valiosa, a menudo sin la posibilidad de comprender incluso lo que sucedió exactamente. Lo más importante: las condiciones de Specter 1.x se pueden crear incluso cuando no es posible un ataque de Specter 1.0.
Los investigadores sostienen que no hay forma de detectar vulnerabilidades como Spectre 1.1 a través de análisis de código o herramientas de compilación. Además, esta vulnerabilidad puede cerrarse a nivel de hierro. También se observa que la responsabilidad de reducir los riesgos de un ataque Spectre exitoso es a menudo responsabilidad de los desarrolladores de software. Teniendo en cuenta que durante los 30 años transcurridos desde la primera demostración pública de un ataque con desbordamiento de búfer, las vulnerabilidades en el software se han vuelto mucho más pequeñas, los autores predicen ataques al mecanismo de ejecución especulativa de la "década" del código de relevancia.
A pesar de lo anterior, los autores creen que una combinación de software y hardware seguro con los beneficios de la protección contra los mecanismos de ejecución especulativa es teóricamente posible. Queda por implementar esto en la práctica, que en el caso de una clase de vulnerabilidades que afectan al hardware, puede llevar años o décadas. Me pregunto si la historia de Specter / Meltdown y sus derivados no se convertirá en un paso hacia algún cambio serio en la práctica del desarrollo de software y hardware.
Descargo de responsabilidad: las opiniones expresadas en este resumen pueden no coincidir siempre con la posición oficial de Kaspersky Lab. Los estimados editores generalmente recomiendan tratar cualquier opinión con escepticismo saludable.