Hacemos todo lo posible para mantener la plataforma Android segura para todos los usuarios en todos los dispositivos. Las actualizaciones de seguridad se publican todos los meses con correcciones para las vulnerabilidades encontradas por miembros del Programa de Recompensas por Vulnerabilidades (VRP) . Sin embargo, también intentamos proteger la plataforma de otras vulnerabilidades potenciales, por ejemplo, utilizando un compilador y mejorando el entorno de prueba. El ecosistema de Android incluye dispositivos con una amplia variedad de capacidades, por lo que todas las decisiones deben ser equilibradas y deben tener en cuenta los datos disponibles.
Este artículo explica cómo seleccionamos los controles de seguridad para circunstancias específicas y cómo se implementan.
Mantener Android seguro requiere un enfoque holístico. Para dificultar la explotación de posibles vulnerabilidades, tomamos decisiones basadas en datos utilizando múltiples principios y técnicas. Cuando se trata de fortalecer la plataforma, se deben responder las siguientes preguntas:
- ¿Qué datos tenemos y cómo pueden ayudarnos a tomar decisiones?
- ¿Qué herramientas de prevención de ataques están disponibles? ¿Cómo se pueden mejorar? ¿En qué situaciones deben aplicarse?
- ¿Qué problemas pueden surgir al utilizar determinadas herramientas de seguridad? ¿Qué posibles diseños deben tenerse en cuenta?
Los principios que utilizamos en nuestras elecciones de seguridad reflejan nuestro enfoque general para proteger a los usuarios de la plataforma Android.
Tome decisiones de seguridad basadas en datos
Para saber para qué componentes de la plataforma serán efectivas ciertas soluciones, recurrimos a varias fuentes. El Programa de Recompensas por Vulnerabilidad de Android (VRP) es quizás el más informativo de todos. Nuestros ingenieros de seguridad analizan todas las vulnerabilidades descubiertas por los participantes del programa, determinando su causa raíz y nivel de gravedad (según estas recomendaciones ). Además, hay informes de errores internos y externos. Ayudan a identificar componentes vulnerables, así como fragmentos de código que a menudo causan fallas. Sabiendo cómo se ven dichos fragmentos y comprendiendo la gravedad y frecuencia de los errores que resultan de ellos, podemos tomar decisiones informadas sobre qué medidas de seguridad serán más efectivas.
Vulnerabilidades de gravedad alta y crítica corregidas en los boletines de seguridad de Android de 2019.
Sin embargo, no confíe únicamente en los informes de vulnerabilidad. Inicialmente dan una imagen distorsionada, ya que los profesionales de la seguridad a menudo prestan atención a las zonas "calientes", es decir, aquellas áreas donde ya se han encontrado vulnerabilidades (por ejemplo, Stagefright ). O pueden buscar vulnerabilidades donde sean más fáciles de detectar utilizando soluciones listas para usar. Por ejemplo, si se publica una herramienta de análisis de seguridad en la plataforma GitHub, muchos profesionales la utilizarán.
Intentamos distribuir nuestros esfuerzos para mejorar la seguridad de manera uniforme. Nuestros equipos prestan atención a los componentes menos explorados y más complejos de la plataforma. Además, las pruebas de fuzzing automatizadas se realizan continuamente en máquinas virtuales y dispositivos Android físicos, lo que le permite encontrar y corregir errores en las primeras etapas de desarrollo. Al decidir qué herramientas utilizar, también analizamos las causas fundamentales y la gravedad de los problemas que encontramos.
Como parte del programa VRP de Android, alentamos a los desarrolladores a agregar cadenas de vulnerabilidades completaslo que le permite rastrear todo el proceso de ataque de principio a fin. Como regla general, los ciberdelincuentes explotan varias vulnerabilidades a la vez, y en tales cadenas estos "paquetes" son claramente visibles, por lo que son muy informativos. Nuestros ingenieros de seguridad analizan tanto cadenas completas como sus enlaces individuales e intentan descubrir nuevas estrategias de ataque en ellas. Este análisis ayuda a determinar estrategias para ayudar a prevenir la explotación secuencial de vulnerabilidades (por ejemplo, asignación de espacio de direcciones aleatoria y métodos de integridad del flujo de control ) y también comprende si el ataque puede mitigarse si el proceso obtiene acceso no deseado a los recursos.
Obviamente, algunas vulnerabilidades se pueden incluir en varias cadenas a la vez y se ubican en un orden diferente. Por lo tanto, es mejor utilizar la "defensa en profundidad", reduciendo la efectividad de las vulnerabilidades individuales y alargando las cadenas de exploits. En este caso, será más difícil para un atacante construir una cadena efectiva y realizar un ataque.
Para comprender las amenazas de seguridad actuales y predecir las tendencias futuras, debe estar constantemente al tanto de la comunidad de seguridad, en particular:
- trabajar en estrecha colaboración con expertos en seguridad de terceros;
- leer publicaciones temáticas y asistir a conferencias;
- estudiar las tecnologías utilizadas por el malware;
- rastrear los últimos desarrollos en el campo de la seguridad;
- participar en proyectos paralelos como KSPP , syzbot, LLVM, Rust, etc.
Como resultado, comprenderá mejor su estrategia de seguridad general, la eficacia de las soluciones existentes y las oportunidades de mejora.
Por qué es necesaria una protección más fuerte
Fortalecimiento de la protección y prevención de ataques
El análisis de los datos ayuda a identificar áreas en las que la mitigación de ataques eficaz puede abordar clases enteras de vulnerabilidades. Por ejemplo, si algunos componentes de la plataforma desarrollan muchas vulnerabilidades debido a errores de desbordamiento de enteros, debe usar un desinfectante de comportamiento no especificado ( UBSan ), como Integer Overflow Sanitizer. Si las vulnerabilidades de acceso a la memoria son comunes, debe usar asignadores de memoria reforzados ( habilitados de forma predeterminada en Android 11 ) y herramientas de prevención de ataques (como Control Flow Integrity ) que sean resistentes al desbordamiento de memoria y las vulnerabilidades Use-After. Gratis.
Antes de hablar sobre el uso de datos, proponemos una clasificación de herramientas para fortalecer la seguridad de la plataforma. Estos son los segmentos principales en los que se pueden dividir todas estas herramientas (aunque algunas herramientas y métodos pueden aplicarse a varias de ellas a la vez):
- Explotar herramientas de eliminación
- Las herramientas de corrección de tiempo de ejecución deterministas detectan comportamientos indefinidos o no deseados e interrumpen la ejecución del programa. Esto elimina la corrupción de datos en la memoria, mientras mantiene la probabilidad de fallas menores. A menudo, estas herramientas se pueden aplicar puntualmente y seguirán siendo eficaces, ya que están diseñadas para errores individuales. Ejemplos: desinfectante de desbordamiento de enteros y BoundsSanitizer .
- . . . . , . : , Control Flow Integrity (CFI), , .
- , . , . : .
-
- . , . , .
Dependiendo del problema específico, decidimos cuál de las herramientas descritas se debe utilizar y cómo. Por ejemplo, cada uno de ellos es adecuado si se trata de un gran proceso que implica el procesamiento de datos poco fiables y un análisis complejo. Las plataformas multimedia han sido una gran demostración de cómo se puede utilizar la descomposición de la arquitectura para mitigar de forma más eficaz las vulnerabilidades y evitar la escalada de privilegios.
Descomposición de la arquitectura y aislamiento de los marcos de los medios en un contexto histórico
Los objetivos de los ataques remotos (NFC, Bluetooth, Wi-Fi y contenido multimedia) se asocian tradicionalmente con las vulnerabilidades más graves, por lo que fortalecer su seguridad debe ser una prioridad. Por lo general, estas vulnerabilidades son causadas por las causas raíz más comunes que se encuentran en el programa VRP, y recientemente agregamos desinfectantes para todas ellas.
Las herramientas de prevención de ataques son útiles para bibliotecas y procesos que establecen o residen dentro de los límites de seguridad (por ejemplo, libbinder , así como las bibliotecas estándar libui , libcore y libcutils), ya que no están vinculados a procesos específicos. Sin embargo, estas bibliotecas son responsables del funcionamiento eficiente y estable de los sistemas, por lo que antes de utilizar un método en particular, necesita una garantía seria de que mejorará la seguridad.
Finalmente, es importante proteger el kernel, dado su alto nivel de privilegios. Todas las bases de código tienen características y funcionalidades diferentes, por lo que la probabilidad de vulnerabilidades en ellas es diferente. Los principales criterios aquí son la estabilidad y el rendimiento. Utilice solo medidas de seguridad eficaces que no interfieran con el trabajo de los usuarios. Por lo tanto, antes de elegir la estrategia óptima para fortalecer la protección, analizamos cuidadosamente todos los datos disponibles relacionados con el kernel.
El enfoque basado en datos ha arrojado resultados tangibles. Después de que se descubrió la vulnerabilidad Stagefright en 2015, comenzamos a recibir informes de una gran cantidad de otras vulnerabilidades críticas en la plataforma de medios Android. Para complicar las cosas, muchos de ellos eran accesibles de forma remota. Hemos realizado una descomposición masiva del sistema Android Nougat y hemos acelerado la reparación de vulnerabilidades en componentes multimedia . Gracias a estos cambios, en 2020 no se reportaron vulnerabilidades críticas en plataformas multimedia a las que se pueda acceder a través de Internet.
Cómo se toma la decisión de implementación
Naturalmente, tiene sentido centrarse en las herramientas de prevención de ataques que funcionan mejor. Para identificarlos, analizamos cómo afecta cada herramienta al rendimiento, cuánto trabajo se requiere para implementarla y admitirla, y si afectará negativamente a la estabilidad del sistema.
Rendimiento
Al elegir una herramienta de prevención de ataques, debe comprender cómo afecta el rendimiento del dispositivo. Si algunos componentes o el sistema en su conjunto no pueden soportar la carga, la vida útil de la batería y el rendimiento general pueden verse reducidos. Esto es especialmente cierto para los dispositivos de nivel de entrada que también necesitan una mayor seguridad. Así, damos preferencia a las soluciones más efectivas que no afecten al rendimiento de los dispositivos.
Al evaluar el rendimiento, prestamos atención no solo al tiempo del procesador, sino también al uso de la memoria, la longitud del código, la duración de la batería y los casos de congelación de la interfaz.... Para asegurarse de que una herramienta funcione bien en todo el ecosistema de Android, es especialmente importante probar los parámetros enumerados en dispositivos de nivel de entrada.
Es muy importante para qué componente se aplican las medidas de protección. Por ejemplo, el enlace se usa más comúnmente para la comunicación entre procesos. Por lo tanto, cualquier carga excesiva afectará instantáneamente al funcionamiento del dispositivo. En el caso de un reproductor multimedia que solo procesa fotogramas a la velocidad original, la situación es diferente. Si la velocidad del video es mucho mayor que la velocidad de visualización, la carga adicional no será tan crítica.
Usamos puntos de referencia para determinar el impacto en el rendimiento de una solución en particular. Si no hay resultados de referencia para un componente, debe obtenerlos, por ejemplo, llamando al códec afectado para decodificar el archivo multimedia. Si la prueba indica una carga inaceptable, hay varias opciones:
- Desactive de forma selectiva la prevención de ataques para las funciones que tienen un impacto significativo en el rendimiento. Normalmente, solo unas pocas funciones consumen recursos en tiempo de ejecución. Si no les aplica mitigación de ataques, puede mantener el rendimiento y maximizar el impacto en la seguridad. A continuación, se muestra un ejemplo de este enfoque para uno de los códecs de medios. Para eliminar los riesgos, las funciones mencionadas deben comprobarse de antemano en busca de errores.
- Optimice el uso de la prevención de ataques. A menudo, esto requiere cambios en el compilador. Por ejemplo, nuestro equipo pasó a usar Integer Overflow Sanitizer y Bounds Sanitizer.
- Algunas opciones de mitigación de ataques, como la resistencia del montón integrada de Scudo, se pueden ajustar para mejorar el rendimiento.
Muchas de estas mejoras requieren cambios en el diseño de LLVM. Como resultado, no solo gana la plataforma Android, sino también otros miembros de la comunidad LLVM.
Implementación y soporte
Al elegir una herramienta de prevención de ataques, debe tener en cuenta no solo las consideraciones de seguridad y rendimiento, sino también los costos de implementación y soporte a largo plazo.
Impacto de las medidas de seguridad en el funcionamiento estable del sistema
Es importante comprender si es posible activar falsamente una herramienta de prevención de ataques en particular. Por ejemplo, si el desinfectante Bounds arroja un error, definitivamente es un acceso denegado (aunque es posible que no se haya utilizado). En el caso del desinfectante de desbordamiento de enteros, son posibles los falsos positivos, ya que un desbordamiento de enteros es a menudo un proceso absolutamente normal e inofensivo.
Por lo tanto, es importante considerar el impacto de las herramientas de prevención de ataques en la estabilidad del sistema. No importa si hubo un falso positivo o hubo una amenaza de seguridad real; en cualquier caso, el usuario experimenta inconvenientes. Aquí nuevamente, observamos que es necesario comprender claramente para qué componentes se deben usar una u otra medida de seguridad. Porque las fallas en algunos componentes tienen un mayor impacto en la estabilidad del sistema. Si Attack Prevention bloquea el códec de medios, el video simplemente dejará de reproducirse. Sin embargo, en caso de error en el proceso
netd
al instalar la actualización, es posible que el dispositivo ya no se encienda. Incluso si los falsos positivos no causan problemas para algunas herramientas anti-ataque (por ejemplo, como es el caso del desinfectante Bounds), seguimos realizando pruebas exhaustivas para asegurarnos de que el dispositivo sea estable. Por ejemplo, los errores de sesgo de uno pueden no fallar normalmente y el desinfectante Bounds interrumpe el proceso e interrumpe la estabilidad del sistema.
También es importante comprender si es posible identificar de antemano todos los componentes que la herramienta de prevención de ataques puede desactivar. Por ejemplo, en el caso del desinfectante Integer Overflow, es muy difícil predecir los riesgos sin realizar pruebas exhaustivas, porque es difícil determinar qué desbordamientos de enteros son intencionales (permitidos) y cuáles pueden causar vulnerabilidades.
Apoyo
Es necesario considerar no solo los posibles problemas en el despliegue de herramientas de prevención de ataques, sino también los detalles de su soporte a largo plazo. Calculamos el tiempo que lleva integrar la herramienta con los sistemas existentes, activarla y depurarla, implementarla en los dispositivos y luego realizar el servicio tras el lanzamiento. La tecnología SELinux es un buen ejemplo. Se necesita mucho tiempo y esfuerzo para crear un conjunto de reglas. Y este conjunto debe mantenerse durante años, independientemente de los cambios de código, así como de la adición o eliminación de funciones individuales.
Nos esforzamos por garantizar que las herramientas de prevención de ataques tengan un impacto mínimo en la estabilidad y que los desarrolladores tengan toda la información que necesitan. Para lograr estos objetivos, estamos mejorando nuestros algoritmos actuales para reducir el número de falsos positivos y publicamos la documentación en source.android.com . Al facilitar la depuración en caso de fallas, puede reducir la carga de mantenimiento para los desarrolladores. Por ejemplo, para facilitar la detección de errores en el desinfectante UBSan, hemos agregado soporte de tiempo de ejecución mínimo de UBSan al sistema de compilación de Android de forma predeterminada. Inicialmente se agregó el tiempo mínimo de ejecución otros desarrolladores de Google específicamente para este propósito. Si el programa falla debido al desinfectante Integer Overflow, se agrega el siguiente fragmento al mensaje de error SIGABRT:
Abort message: 'ubsan: sub-overflow'
Después de ver este mensaje, los desarrolladores comprenderán que es necesario habilitar el modo de diagnóstico para imprimir información sobre la falla:
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:2188:32: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
A su vez, SELinux cuenta con una herramienta audit2allow que le permite proponer reglas que permitan ciertas operaciones bloqueadas:
adb logcat -d | audit2allow -p policy
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };
Si bien es posible que audit2allow no siempre sugiera las opciones correctas, es de gran ayuda para los desarrolladores nuevos en SELinux.
Conclusión
Con cada lanzamiento de Android, le traemos nuevas herramientas que protegen todo el ecosistema, asegurando el rendimiento y la estabilidad que necesita. El análisis de datos juega un papel importante en esto. Esperamos que este artículo le haya ayudado a comprender mejor los desafíos de implementar nuevas herramientas de prevención de ataques y cómo los enfrentamos.
Gracias a nuestros colegas y autores: Kevin Deus, Joel Galenson, Billy Lau, Ivan Lozano - Expertos en seguridad y privacidad de Android. Un agradecimiento especial a Zviad Kardava y Jeff Van Der Stup por su ayuda en la preparación de este artículo.