Publicado por Jeff Vander Stoep, Equipo de seguridad de Android 
Android depende mucho del kernel de Linux para la aplicación de su modelo de seguridad. Para proteger mejor el kernel, hemos habilitado varios mecanismos dentro de Android. A un nivel elevado, estas protecciones se agrupan en dos categorías: protecciones de la memoria y reducción de la superficie de ataque.

Protecciones de la memoria


Una de las funciones de seguridad más importantes que proporciona el kernel es la protección de la memoria para procesos de espacio del usuario bajo la forma de separación de espacios de direcciones. A diferencia de los procesos de espacio del usuario, las diferentes tareas del kernel tienen lugar dentro de un espacio de direcciones y una vulnerabilidad en cualquier punto del kernel puede afectar sectores no relacionados de la memoria del sistema. Las protecciones de memoria del kernel están diseñadas para preservar la integridad de este a pesar de las vulnerabilidades.

Marca la memoria como de solo lectura o de no ejecución


Esta función segmenta memoria del kernel en secciones lógicas y fija permisos de acceso a páginas con restricciones en cada sección. El código se marca como “de solo lectura” y “de ejecución”. Las secciones de datos se marcan como de no ejecución y se segmentan en secciones de solo lectura y de lectura y escritura. Esta función se habilita con la opción de configuración CONFIG_DEBUG_RODATA. Fue creada por Kees Cook y se basa en un subconjunto de la función KERNEXEC de Grsecurity, creado por Brad Spengler, y la función CONFIG_STRICT_MEMORY_RWX de Qualcomm, creada por Larry Bassel y Laura Abbott. CONFIG_DEBUG_RODATA se aplicó al kernel ascendente para arm/arm64 y se adaptó al kernel común 3.18+ arm/arm64 de Android.

Restringe el acceso del kernel al espacio del usuario


Esta función mejora la protección del kernel al evitar que acceda de manera directa a la memoria del espacio de usuarios. Esto puede dificultar varios ataques, ya que los atacantes tienen un control considerablemente inferior de la memoria ejecutable del kernel, en particular cuando CONFIG_DEBUG_RODATA está habilitado. Ya existían funciones similares; la más antigua fue UDEREF, de Grsecurity. Esta función se habilita con la opción de configuración CONFIG_CPU_SW_DOMAIN_PAN, y fue implementada por Russell King para ARMv7 y adaptada al kernel 4.1 de Android, creado por Kees Cook.

Mejora la protección contra desbordamientos del búfer de pila


De manera muy similar a stack-protector, opción que lo precedió, stack-protector-strong brinda protección contra desbordamientos del búfer de pila, aunque también ofrece cobertura para más tipos de arreglos; por ejemplo, los arreglos de caracteres que originalmente eran los únicos en recibir protección. Stack-protector-strong fue implementado por Han Shan y se agregó al compilador gcc 4.9.

Reducción de la superficie de ataque


El propósito de la reducción de la superficie de ataque es exponer menos puntos de entrada al kernel sin dañar la funcionalidad legítima. Reducir la superficie de ataque puede implicar eliminar código o el acceso a puntos de entrada, o exponer funciones de manera selectiva.

Elimina el acceso predeterminado a funciones de depuración


El sistema de rendimiento del kernel proporciona infraestructura para la medición del rendimiento y puede usarse para analizar el kernel y las aplicaciones del espacio del usuario. Es una valiosa herramienta para los desarrolladores, pero agrega una superficie de ataque innecesaria para la amplia mayoría de los usuarios de Android. En Android Nougat, el acceso al sistema de rendimiento estará bloqueado de forma predeterminada. Los desarrolladores podrán, de todos modos, acceder a él habilitando la configuración para desarrolladores y usando adb para configurar una propiedad: “adb shell setprop security.perf_harden 0”.

El patchset para bloquear el acceso al sistema de rendimiento puede dividirse en secciones de kernel y espacio del usuario. La revisión de kernel fue creada por Ben Hutchings y deriva de CONFIG_GRKERNSEC_PERF_HARDEN de Grsecurity, creada por Brad Spengler. Daniel Micay aportólos cambios en el espacio del usuario. Gracias Wish Wu y a los demás por actuar con responsabilidad y divulgar vulnerabilidades del sistema de rendimiento.

Restringe el acceso de las aplicaciones a comandos ioctl


Una gran parte del modelo de seguridad de Android se describe y se aplica a través de SELinux. La llamada de sistema ioctl() representó una brecha importante en la granularidad de aplicación a través de SELinux. La admisión de comandos Ioctl con SELinux se agregó como un medio para proporcionar control por comando a través de la llamada de sistema mediante SELinux.

La mayoría de las vulnerabilidades de kernel informadas en Android tienen lugar en controladores y se accede a ellas con la llamada de sistema ioctl; por ejemplo, CVE-2016-0820. Algunos comandos ioctl son necesarios para aplicaciones de terceros. Sin embargo, esto no sucede con la mayoría de ellos y el acceso puede restringirse sin afectar la funcionalidad legítima. En Android Nougat, solo se encuentra disponible una pequeña lista blanca de comandos ioctl de socket para las aplicaciones. Para un grupo selecto de dispositivos, se restringió se manera similar el acceso de las aplicaciones a ioctl de GPU.

Solicita seccomp-bpf


Seccomp proporciona un mecanismo adicional de espacios, el cual permite a un proceso restringir las llamadas de sistema y los argumentos de estas que estén disponibles a través de un filtro configurable. La restricción de la disponibilidad de llamadas de sistema puede reducir de manera dramática la superficie de ataque expuesta del kernel. Debido a que seccomp se presentó primero para dispositivos Nexus en Lollipop, su disponibilidad en el ecosistema de Android ha mejorado de forma sostenida. Con Android Nougat, la compatibilidad con seccomp es un requisito para todos los dispositivos. En Android Nougat, usaremos seccomp en los procesos mediaextractor y mediacodec como parte del esfuerzo de protección de medios.

Esfuerzos en curso


Hay en desarrollo otros proyectos destinados a proteger el kernel:
  • A través del proyecto de autoprotección de kernel, se desarrollan defensas de tiempo de ejecución y compilación para el kernel ascendente.
  • En el proyecto de código abierto de Android (AOSP), hay en curso tareas de ajuste de espacios y de reducción de la superficie de ataque con SELinux.
  • Minijail proporciona un mecanismo práctico para aplicar muchas funciones de contención y espacios seguros que ofrece el kernel, como los filtros seccomp y los espacios de nombres.
  • Los proyectos como kasan y kcov ayudan a los fuzzers a descubrir la causa principal de las fallas y a construir de manera inteligente casos de prueba que aumentan la cobertura del código, lo cual potencia finalmente la eficacia del proceso de búsqueda de errores.

Debido a estos y otros esfuerzos, esperamos que continúe el proceso de mejoramiento de la seguridad del kernel. Como siempre, apreciamos los comentarios sobre nuestro trabajo y recibimos con gusto sugerencias para mejorar Android. Escríbenos a security@android.com.