Semana de la seguridad 24: Rowhammer en Android y la complejidad de las vulnerabilidades de hardware

Me gusta leer artículos científicos que investigan las vulnerabilidades de la computadora. Tienen algo de lo que a menudo carece la industria de la seguridad de la información, a saber, precaución al formular ciertas suposiciones. Esto es una virtud, pero hay un inconveniente: por regla general, los beneficios prácticos o el daño de un hecho recién descubierto no son obvios, se investigan fenómenos demasiado fundamentales. Este año aprendimos mucho sobre nuevas vulnerabilidades de hardware, comenzando con Spectre y Meltdown, y generalmente este nuevo conocimiento aparece en forma de trabajo científico. Las cualidades de estos problemas de hardware son apropiadas: toda clase de dispositivos están expuestos a ellos, es difícil (o incluso imposible) cerrar completamente el parche de software, el daño potencial también es incomprensible. Qué puedo decir, a veces es difícil entender cómo funcionan en general.

Este es aproximadamente el caso de las vulnerabilidades de la clase Rowhammer. Hace cuatro años, se descubrió una posibilidad fundamental de cambiar el bit "vecino" en el módulo RAM mediante operaciones regulares de lectura / escritura. Desde entonces, han surgido nuevos estudios que muestran cómo aplicar esta característica de chips de memoria compacta para ataques prácticos. La semana pasada, un equipo de científicos de diferentes países mostró un ataque práctico a los teléfonos inteligentes RAMpage Android ( noticias , investigación ). ¿Cuán real es este ataque? Tratemos de resolverlo (spoiler: aún no está claro).

Permítame recordarle que el ataque Rowhammer utiliza las características fundamentales de los chips de memoria. Específicamente, un cambio en la carga cuando se escribe en una celda específica (más precisamente, una serie de celdas) también afecta a las celdas vecinas (filas). Por lo general, esto no es un problema, ya que a ciertos intervalos se actualizan los cargos en todas las celdas. Pero si a menudo realiza operaciones de lectura y escritura (decenas y cientos de miles de veces), puede cambiar el valor en las celdas de memoria a las que inicialmente no tuvo acceso (todo lo anterior es una simplificación vulgar que raya en el crimen, y la verdad es solo en el trabajo científico original ). Adaptar esta función de memoria para un ataque real no es fácil: requiere la combinación correcta de derechos de acceso al sistema, la ubicación del código en la memoria, el acceso directo a la memoria sin almacenamiento en caché, y así sucesivamente. No de inmediato, pero en cuatro años hubo muchos ejemplos de tales combinaciones, y Rowhammer pasó de ser una teoría linda a una práctica dura.


Cuando necesita una imagen sobre computadoras, martillos y seguridad

Ni siquiera intentaré volver a contar el ataque RAMpage en palabras simples. Este ataque evita los parches introducidos en Android después del descubrimiento (por aproximadamente el mismo grupo de investigadores) del ataque Drammer en 2016. La combinación de varios métodos previamente conocidos que brindan acceso directo a RAM en el lugar correcto y las características de la versión moderna de Android (en el experimento que usamos el teléfono LG G4 con Android 7.1.1) nos permitió obtener derechos de superusuario en un teléfono completamente parcheado.

Lo que no es característico para la investigación sobre una nueva vulnerabilidad, los autores de RAMPage también ofrecen una forma de cerrar la vulnerabilidad, y con una caída muy pequeña en el rendimiento (según Google, la caída aún es significativa). Además, la mitigación (también se le ocurrió el nombre: GuardION) le permite activar las optimizaciones desactivadas en Android después de un estudio anterior.



En las mejores tradiciones del marketing moderno de vulnerabilidades, las vulnerabilidades (y parches) han creado el sitio y los logotipos . Pero como son científicos, las preguntas frecuentes en este sitio son extremadamente honestas: "No, esto no es Spectre, ni siquiera cerca". "No, no le mostraremos PoC". "No sabemos si su teléfono es propenso , solo teníamos un dinero ". Es cierto que en el sitio puedes descargar una aplicación que te permite probar tu gadget en busca de vulnerabilidades. El código de mitigación sugerido también está disponible en GitHub . Google no está dispuesto a exagerar el peligro de la investigación: el ataque "no funciona en dispositivos compatibles con Google Android". Me gustaría decir algo bueno sobre la fragmentación de Android y la diferencia entre compatible y usado, pero de alguna manera en otro momento.

¿Qué, para decirlo en ruso ordinario, ha sucedido? Los investigadores han elevado el listón por la practicidad de otro ataque que explota una vulnerabilidad de hardware. Todavía no ha sido utilizado (y es poco probable que lo sea) por el crimen, y en general, el camino no es corto desde el estado "obtuvieron la raíz en el laboratorio" hasta "podemos atacar un número significativo de dispositivos de usuarios reales". Google es consciente y, de alguna manera, al menos en las versiones más recientes de Android, mantiene el problema bajo control. Dichos estudios requieren mucho tiempo y el peligro radica en la posible transición brusca de la cantidad (horas hombre empleadas) a la calidad. A saber: en la apariencia de un agujero explotado relativamente fácil (al menos como Meltdown), que se puede cerrar ya sea comprando un nuevo dispositivo o por una caída en el rendimiento a veces.

Sin embargo, la propuesta anterior ya es una suposición imprudente ( pero es posible para el autor del texto, no es un científico ). Mientras tanto, otro grupo de investigadores pareció encontrar otra vulnerabilidad de hardware, esta vez en la función de hyperthreading en los procesadores Intel. Además, la vulnerabilidad se utilizó para robar una clave de cifrado de un proceso que se ejecuta en un subproceso vecino del mismo núcleo. Y los mantenedores de OpenBSD quedaron tan impresionados con los resultados que decidieron desactivar el soporte para la funcionalidad del procesador en el kit de distribución (con obvias implicaciones de rendimiento). La investigación está programada para su publicación en la conferencia Black Hat en agosto. Continuamos la observación.

Descargo de responsabilidad: Ahhh, olvidé agregar un descargo de responsabilidad a la publicación anterior. Que hacer ¿Qué me pasará a mí? ¿Me despedirán? La Tierra volará en el eje celeste? ¿Encuentra una vulnerabilidad en los cables de alimentación? Quien soy yo ¿Qué es este lugar? Una luz blanca tan brillante: 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.

Source: https://habr.com/ru/post/es415979/


All Articles