Actualizaciones y recursos de seguridad

El equipo de seguridad de Android es responsable de administrar las vulnerabilidades de seguridad descubiertas en la plataforma de Android y muchas de las apps principales de Android incluidas en los dispositivos Android.

El equipo de seguridad de Android encuentra vulnerabilidades de seguridad a través de investigaciones internas y también responde a los errores que informan terceros. Las fuentes de errores externos incluyen problemas informados a través del formulario de vulnerabilidades, investigaciones académicas publicadas y previamente publicadas, mantenedores de proyectos de código abierto upstream, notificaciones de nuestros socios fabricantes de dispositivos y problemas divulgados públicamente en blogs o redes sociales.

Cómo informar problemas de seguridad

Cualquier desarrollador, usuario de Android o investigador de seguridad puede notificar al equipo de seguridad de Android sobre posibles problemas de seguridad a través del formulario de vulnerabilidades.

Los errores marcados como problemas de seguridad no son visibles de forma externa, pero es posible que, con el tiempo, se vuelvan visibles después de que se evalúe o resuelva el problema. Si planeas enviar un parche o una prueba del Conjunto de pruebas de compatibilidad (CTS) para resolver un problema de seguridad, adjúntalo al informe de errores y espera una respuesta antes de subir el código a AOSP.

Clasificación de errores

La primera tarea para controlar una vulnerabilidad de seguridad es identificar la gravedad del error y cuál es el componente de Android afectado. La gravedad determina cómo se prioriza el problema, y el componente determina quién corrige el error, a quién se le notifica y cómo se implementa la corrección a los usuarios.

Tipos de contexto

En esta tabla, se incluyen las definiciones de los contextos de seguridad de hardware y software. El contexto se puede definir según la sensibilidad de los datos que suele procesar o el área en la que se ejecuta. No todos los contextos de seguridad se aplican a todos los sistemas. Esta tabla está ordenada de menor a mayor privilegio.

Tipo de contexto Definición de tipo
Contexto restringido Un entorno de ejecución restringido en el que solo se proporcionan los permisos mínimos.

Por ejemplo, apps de confianza que procesan datos no confiables en un entorno de zona de pruebas.
Contexto sin privilegios Un entorno de ejecución típico que espera el código sin privilegios.

Por ejemplo, una app para Android que se ejecuta en un dominio de SELinux con el atributo untrusted_app_all.
Contexto con privilegios Un entorno de ejecución con privilegios que puede tener acceso a permisos elevados, controla la PII de varios usuarios o mantiene la integridad del sistema.

Por ejemplo, una app para Android con capacidades que el dominio untrusted_app de SELinux prohibiría o con acceso a permisos privileged|signature.
Kernel del SO Funcionalidad que tenga las siguientes características:
  • es parte del kernel.
  • se ejecuta en el mismo contexto de CPU que el kernel (por ejemplo, los controladores de dispositivos).
  • tiene acceso directo a la memoria del kernel (por ejemplo, componentes de hardware en el dispositivo).
  • tiene la capacidad de cargar secuencias de comandos en un componente del kernel (por ejemplo, eBPF).
  • es uno de los pocos servicios de usuario que se consideran equivalentes al kernel (como apexd, bpfloader, init, ueventd y vold).
Base de hardware confiable (THB) Componentes de hardware discretos, generalmente en el SoC, que proporcionan funcionalidad fundamental para los casos de uso principales del dispositivo (como bandas base celulares, DSP, GPUs y procesadores de IA).
Cadena de bootloader Es un componente que configura el dispositivo durante el inicio y, luego, pasa el control al SO Android.
Entorno de ejecución confiable (TEE) Un componente diseñado para estar protegido incluso de un kernel de SO hostil (por ejemplo, TrustZone y hipervisores, como pKVM, que protegen las máquinas virtuales del kernel del SO).
Secure Enclave / Elemento seguro (SE) Es un componente de hardware opcional diseñado para estar protegido de todos los demás componentes del dispositivo y de los ataques físicos, como se define en la Introducción a los elementos seguros.

Esto incluye el chip Titan-M presente en algunos dispositivos Android.

Gravedad

La gravedad de un error suele reflejar el daño potencial que podría ocurrir si se aprovechara con éxito. Usa los siguientes criterios para determinar la gravedad.

Clasificación Consecuencia de un aprovechamiento exitoso
Crítico
  • Ejecución de código arbitraria en el TEE o el SE
  • Elusión de mecanismos de software diseñados para evitar que los componentes de software o hardware relacionados con la seguridad funcionen de manera incorrecta (por ejemplo, protecciones térmicas)
  • Acceso remoto a credenciales sensibles que se usan para la autenticación de servicios remotos (por ejemplo, contraseñas de cuentas o tokens de portador)
  • Ejecución remota de código arbitrario dentro del contexto de la banda base celular sin interacción del usuario (por ejemplo, aprovechar un error en el servicio de radio celular)
  • Ejecución remota de código arbitrario en un contexto con privilegios, la cadena de arranque, el THB o el kernel del SO
  • Omisión remota de los requisitos de interacción del usuario en la instalación de paquetes o un comportamiento equivalente
  • Omisión remota de los requisitos de interacción del usuario para la configuración básica de desarrollador, seguridad o privacidad
  • Denegación del servicio remota persistente (permanente, que requiere volver a escribir en la memoria flash todo el sistema operativo o restablecer la configuración de fábrica)
  • Omisión remota del inicio seguro
  • Acceso no autorizado a los datos protegidos por el SE, incluido el acceso habilitado por claves débiles en el SE
Alta
  • Un bypass completo de una función de seguridad principal (por ejemplo, SELinux, FBE o seccomp)
  • Una omisión general para una defensa en profundidad o una tecnología de mitigación de exploits en la cadena de bootloader, TEE o SE
  • Un bypass general para las protecciones del sistema operativo que revelan el contenido de la memoria o del archivo en los límites de la app, el usuario o el perfil
  • Ataques contra un SE que generan una baja a una implementación menos segura
  • Pivotar desde un firmware de hardware sin procesar comprometido al que se puede acceder de forma remota (por ejemplo, la banda base, el procesador de comunicación (CP)) al kernel del procesador de apps (AP) o los mecanismos de omisión diseñados para aislar el firmware de hardware sin procesar del kernel del AP
  • Omisión de la protección del dispositivo, la protección contra el restablecimiento de la configuración de fábrica o las restricciones del operador
  • Omisión de los requisitos de interacción del usuario que protege el TEE
  • Vulnerabilidad criptográfica que permite ataques contra protocolos de extremo a extremo, incluidos los ataques contra la seguridad de la capa de transporte (TLS) y Bluetooth (BT).
  • Acceso local a credenciales sensibles que se usan para la autenticación de servicios remotos (por ejemplo, contraseñas de cuentas o tokens de portador)
  • Ejecución de código arbitrario local en un contexto con privilegios, la cadena del bootloader, THB o el kernel del SO
  • Omisión del inicio seguro local
  • Omisión de la pantalla de bloqueo
  • Omisión local de los requisitos de interacción del usuario para la configuración básica del desarrollador, la seguridad o la privacidad
  • Omisión local de los requisitos de interacción del usuario en la instalación de paquetes o un comportamiento equivalente
  • Denegación local persistente del servicio (permanente, que requiere volver a escribir en la memoria flash todo el sistema operativo o restablecer la configuración de fábrica)
  • Acceso remoto a datos protegidos (es decir, datos limitados a un contexto privilegiado)
  • Ejecución remota de código arbitrario en un contexto sin privilegios
  • Prevención remota del acceso al servicio de telefonía celular o Wi-Fi sin interacción del usuario (por ejemplo, hacer que falle el servicio de radio celular con un paquete con el formato incorrecto)
  • Omisión remota de los requisitos de interacción del usuario (acceso a funciones o datos que deberían requerir la iniciación o el permiso del usuario)
  • Prevención dirigida del acceso a los servicios de emergencia
  • Transmitir información sensible a través de un protocolo de red no seguro (por ejemplo, HTTP y Bluetooth sin encriptar) cuando el solicitante espera una transmisión segura Ten en cuenta que esto no se aplica a la encriptación de Wi-Fi (como WEP).
  • Acceso no autorizado a los datos protegidos por el TEE, incluido el acceso habilitado por claves débiles en el TEE
Moderado
  • Un bypass general para una defensa en profundidad o una tecnología de mitigación de exploits en un contexto con privilegios, THB o el kernel del SO
  • Un bypass general para las protecciones del sistema operativo que revelan el estado del proceso o los metadatos en los límites de la app, el usuario o el perfil
  • Omitir la encriptación o autenticación de Wi-Fi
  • Vulnerabilidad criptográfica en primitivas criptográficas estándar que permite la filtración de texto sin formato (no primitivas usadas en TLS)
  • Acceso local a datos protegidos (es decir, datos que se limitan a un contexto privilegiado)
  • Ejecución de código arbitrario local en un contexto sin privilegios
  • Omisión local de los requisitos de interacción del usuario (acceso a funciones o datos que, por lo general, requieren la iniciación o el permiso del usuario)
  • Acceso remoto a datos sin protección (es decir, datos a los que normalmente puede acceder cualquier app instalada de forma local)
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación del servicio del dispositivo temporal remota (bloqueo o reinicio remoto)
Baja
  • Una omisión general para una defensa en profundidad a nivel del usuario o una tecnología de mitigación de exploits en un contexto sin privilegios
  • Omisión de un permiso normal de nivel de protección
  • Vulnerabilidad criptográfica en un uso no estándar
  • Omisión general de las funciones de personalización integradas en el dispositivo, como Voice Match o Face Match
  • Documentación incorrecta que puede generar una vulnerabilidad de seguridad
  • Ejecución de código arbitrario local en un contexto restringido
  • Texto definido por el sistema que incluye una descripción engañosa que crea una expectativa de seguridad falsa
Impacto de seguridad​ despreciable (NSI​)
  • Una vulnerabilidad cuyo impacto se mitigó con uno o más modificadores de calificación o cambios de arquitectura específicos de la versión, de modo que la gravedad efectiva sea inferior a Baja, aunque el problema de código subyacente pueda permanecer
  • Cualquier vulnerabilidad que requiera un sistema de archivos con el formato incorrecto, si ese sistema de archivos siempre se adopta o encripta antes de usarlo
  • Denegación local temporal del servicio, por ejemplo, cuando la condición se puede resolver reiniciando el dispositivo o desinstalando la app que la activa.

Modificadores de tarifas

Si bien la gravedad de las vulnerabilidades de seguridad suele ser fácil de identificar, las calificaciones pueden cambiar según las circunstancias.

Motivo Efecto
Requiere ejecutarse como un contexto con privilegios para ejecutar el ataque (no se aplica a TEE, SE ni hipervisores como pKVM). Gravedad -1
Los detalles específicos de la vulnerabilidad limitan el impacto del problema. Gravedad -1
Omisión de la autenticación biométrica que requiere información biométrica directamente del propietario del dispositivo Gravedad -1
Las configuraciones del compilador o de la plataforma mitigan una vulnerabilidad en el código fuente. Gravedad moderada si la vulnerabilidad subyacente es moderada o superior
Requiere acceso físico a los componentes internos del dispositivo y es posible incluso si el dispositivo está apagado o no se desbloqueó desde que se encendió. Gravedad -1
Requiere acceso físico a los componentes internos del dispositivo mientras está encendido y se desbloqueó anteriormente. Gravedad -2
Un ataque local que requiere que se desbloquee la cadena del bootloader No superior a Bajo
Un ataque local que requiere que el Modo de desarrollador o cualquier configuración persistente del Modo de desarrollador esté habilitado en el dispositivo (y no es un error en el Modo de desarrollador). No superior a Bajo
Si ningún dominio de SELinux puede realizar la operación según la SEPolicy proporcionada por Google Impacto de seguridad despreciable

Local, proximal y remoto

Un vector de ataque remoto indica que el error se puede aprovechar sin instalar una app ni sin acceso físico a un dispositivo. Esto incluye errores que se pueden activar cuando se navega a una página web, se lee un correo electrónico, se recibe un mensaje SMS o se conecta a una red hostil.

Los vectores de ataque proximales se consideran remotos. Estos incluyen errores que solo puede aprovechar un atacante que está físicamente cerca del dispositivo de destino, por ejemplo, un error que requiere el envío de paquetes de Wi-Fi o Bluetooth con el formato incorrecto. Consideramos que los ataques de banda ultraancha (UWB) y basados en NFC son proximales y, por lo tanto, remotos.

Los ataques locales requieren que el atacante tenga acceso previo a la víctima. En un ejemplo hipotético solo de software, esto podría ser a través de una app maliciosa que la víctima instaló o una app instantánea a la que dio su consentimiento para que se ejecute.

Los dispositivos vinculados correctamente (como los dispositivos complementarios Bluetooth) se consideran locales. Hacemos una distinción entre un dispositivo vinculado y un dispositivo que participa en un flujo de vinculación.

  • Los errores que degradan la capacidad del usuario de identificar el otro dispositivo con el que se vincula (es decir, la autenticación) se consideran proximales y, por lo tanto, remotos.
  • Los errores que ocurren durante el flujo de vinculación, pero antes de que se establezca el consentimiento del usuario (es decir, la autorización), se consideran proximales y, por lo tanto, remotos.
  • Los errores que ocurren después de que se establece el consentimiento del usuario se consideran locales, incluso si la vinculación falla en última instancia.

Los vectores de ataque físicos se consideran locales. Estos incluyen errores que solo puede aprovechar un atacante que tenga acceso físico al dispositivo, por ejemplo, un error en una pantalla de bloqueo o uno que requiera conectar un cable USB. Dado que es común que los dispositivos estén desbloqueados mientras están conectados a USB, los ataques que requieren una conexión USB tienen la misma gravedad, independientemente de si el dispositivo debe estar desbloqueado o no.

Seguridad de red

Android supone que todas las redes son hostiles y podrían estar inyectando ataques o espiando el tráfico. Si bien la seguridad de la capa de vínculo (por ejemplo, la encriptación de Wi-Fi) protege la comunicación entre un dispositivo y el punto de acceso al que está conectado, no hace nada para proteger los vínculos restantes en la cadena entre el dispositivo y los servidores con los que se comunica.

Por el contrario, HTTPS suele proteger toda la comunicación de extremo a extremo, encriptando los datos en su fuente y, luego, desencriptando y verificando solo una vez que llegan a su destino final. Por este motivo, las vulnerabilidades que comprometen la seguridad de la red de la capa de vínculo se clasifican como menos graves que las vulnerabilidades de HTTPS/TLS: la encriptación de Wi-Fi por sí sola no es suficiente para la mayoría de las comunicaciones en Internet.

Autenticación biométrica

La autenticación biométrica es un campo desafiante, y hasta los mejores sistemas pueden ser engañados por una coincidencia cercana (consulta Blog para desarrolladores de Android: Mejoras en la pantalla de bloqueo y la autenticación en Android 11). Estas clasificaciones de gravedad distinguen entre dos clases de ataques y tienen como objetivo reflejar el riesgo real para el usuario final.

La primera clase de ataques permite omitir la autenticación biométrica de manera generalizable, sin datos biométricos de alta calidad del propietario. Por ejemplo, si un atacante puede colocar un chicle en un sensor de huellas dactilares y este otorga acceso al dispositivo en función de los residuos que quedan en el sensor, se trata de un ataque simple que se podría realizar en cualquier dispositivo susceptible. No requiere ningún conocimiento del propietario del dispositivo. Dado que es generalizable y puede afectar a una mayor cantidad de usuarios, este ataque recibe la calificación de gravedad completa (por ejemplo, alta, para un bypass de la pantalla de bloqueo).

La otra clase de ataques suele implicar un instrumento de ataque de presentación (falsificación) basado en el propietario del dispositivo. A veces, esta información biométrica es relativamente fácil de obtener (por ejemplo, si la foto de perfil de alguien en las redes sociales es suficiente para engañar a la autenticación biométrica, un bypass biométrico recibiría la calificación de gravedad completa). Sin embargo, si un atacante necesitara adquirir datos biométricos directamente del propietario del dispositivo (por ejemplo, un escaneo infrarrojo de su rostro), esa barrera es lo suficientemente significativa como para limitar la cantidad de personas afectadas por el ataque, por lo que hay un modificador de -1.

SYSTEM_ALERT_WINDOW y tapjacking

Para obtener información sobre nuestras políticas con respecto a SYSTEM_ALERT_WINDOW y el ataque tapjacking, consulta la sección "Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen" de la página Bugs with no security impact de BugHunter University.

Seguridad multiusuario en el SO Android Automotive

El SO Android Automotive adopta un modelo de seguridad multiusuario diferente de los demás factores de forma. Cada usuario de Android está diseñado para que lo use una persona física diferente. Por ejemplo, se puede asignar un usuario invitado temporal a un amigo que le pide prestado el vehículo al propietario. Para admitir casos de uso como este, los usuarios tienen acceso de forma predeterminada a los componentes necesarios para usar el vehículo, como la configuración de Wi-Fi y de la red celular.

Componente afectado

El equipo de desarrollo responsable de corregir el error depende del componente en el que se encuentra. Puede ser un componente principal de la plataforma de Android, un controlador de kernel que proporciona un fabricante de equipos originales (OEM) o una de las apps precargadas en dispositivos Pixel.

El equipo de Ingeniería de Android corrige los errores en el código del AOSP. Los errores de baja gravedad, los errores en ciertos componentes o los errores que ya son de conocimiento público se pueden corregir directamente en la rama principal de AOSP disponible públicamente. De lo contrario, primero se corrigen en nuestros repositorios internos.

El componente también es un factor en la forma en que los usuarios reciben actualizaciones. Un error en el framework o el kernel requiere una actualización de firmware inalámbrica (OTA) que cada OEM debe enviar. Un error en una app o biblioteca publicada en Google Play (por ejemplo, Gmail, los Servicios de Google Play o WebView) se puede enviar a los usuarios de Android como una actualización de Google Play.

Notificar a los socios

Cuando se corrija una vulnerabilidad de seguridad en AOSP en un boletín de seguridad de Android, notificaremos a los socios de Android los detalles del problema y les proporcionaremos parches. La lista de versiones compatibles con la portabilidad a versiones anteriores cambia con cada versión nueva de Android. Comunícate con el fabricante del dispositivo para obtener la lista de dispositivos compatibles.

Cómo lanzar código en AOSP

Si el error de seguridad está en un componente de AOSP, la corrección se envía a AOSP después de que se lanza la actualización OTA a los usuarios. Las correcciones de problemas de baja gravedad se pueden enviar directamente a la rama principal de AOSP antes de que estén disponibles para los dispositivos a través de una actualización inalámbrica.

Cómo recibir actualizaciones de Android

Por lo general, las actualizaciones del sistema Android se entregan a los dispositivos a través de paquetes de actualización inalámbrica. Estas actualizaciones pueden provenir del OEM que produjo el dispositivo o del operador que le brinda servicio. Las actualizaciones de los dispositivos Google Pixel provienen del equipo de Google Pixel después de pasar por un procedimiento de prueba de aceptación técnica (TA) del operador. Google también publica imágenes de fábrica de Pixel que se pueden transferir a los dispositivos.

Actualiza los servicios de Google

Además de proporcionar parches para errores de seguridad, el equipo de seguridad de Android revisa los errores de seguridad para determinar si hay otras formas de proteger a los usuarios. Por ejemplo, Google Play analiza todas las apps y quita las que intentan aprovechar un error de seguridad. En el caso de las apps instaladas desde fuera de Google Play, los dispositivos con los Servicios de Google Play también pueden usar la función Verificar apps para advertir a los usuarios sobre las apps que pueden ser potencialmente dañinas.

Otros recursos

Información para desarrolladores de apps para Android: https://developer.android.com

La información de seguridad se encuentra en los sitios de Android Open Source y de desarrolladores. Estos son algunos buenos puntos de partida:

Informes

A veces, el equipo de seguridad de Android publica informes o documentos técnicos. Consulta Informes de seguridad para obtener más detalles.