Google a Samsung: deja de jugar con el kernel Linux, daña la seguridad de Android

Un investigador del Proyecto Cero de Google, ha «regañado» a Samsung (y en general a otros socios que trabajan en su plataforma de móviles Android) por las modificaciones realizadas en el código del kernel Linux que ta terminado exponiendo a los terminales a más errores de seguridad.

Fabricantes de teléfonos inteligentes como Samsung crean más vulnerabilidades al agregar controladores personalizados posteriores con acceso directo del hardware al kernel de Linux que forma la base de Android. Los analistas de seguridad de Google recomiendan a los proveedores que utilicen las características de seguridad que ya existen en el kernel de Linux.

En Android, explica el investigador, es normal que los proveedores agreguen código específico del dispositivo al kernel. Este código es una fuente frecuente de vulnerabilidades de seguridad. Android ha estado reduciendo el impacto de dicho código al bloquear qué procesos tienen acceso a los controladores de dispositivos, que a menudo son específicos del proveedor. Los teléfonos Android modernos acceden a dispositivos de hardware a través de procesos auxiliares dedicados, que forman la Capa de abstracción de hardware (HAL).

Los fabricantes complican la seguridad de Android

Desafortunadamente, es más difícil bloquear genéricamente la superficie de ataque que se crea cuando los proveedores modifican la funcionalidad del núcleo. Incluso cuando estas personalizaciones posteriores están destinadas a agregar seguridad a un dispositivo, también introducen errores de seguridad. 

De hecho, las mitigaciones de seguridad del núcleo provistas por Samsung introdujeron un error de corrupción de memoria etiquetado como SVE-2019-16132 del que Google informó a Samsung el pasado noviembre. 

El investigador describe cómo encontró el bug en el núcleo de Android usado personalizado por Samsung en el modelo Galaxy A50 y en concreto en el subsistema de seguridad adicional (denominado «PROCA», abreviatura de «Autenticador de proceso») para rastrear las identidades del proceso. Al combinar varios problemas de lógica en este subsistema (que, por sí solos, ya pueden causar un desajuste entre el estado de seguimiento y el estado real del proceso) con un patrón de código frágil, es posible causar esta corrupción de memoria. 

También describe como preparó un exploit de manera sencilla y describe cómo una segunda vulnerabilidad, que se había corregido hace bastante tiempo en el núcleo de Android y en las versiones estables del sistema, pero no estaba corregida en el núcleo de Samsung, ayudó a su explotación.

La solución parece difícil ante las variaciones que realizan los fabricantes sobre Android. Y no solo en el núcleo, sino con interfaces y aplicaciones que que complican también la seguridad de la plataforma. Lo ideal sería utilizar el Android «más puro» (AOSP) que proporciona Google y que fuera este el encargado de la seguridad del sistema. Con tantos cambios y los centenares de modelos distintos que se comercializan cada año parece imposible.