Actualizaciones y recursos de seguridad

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

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

Reportar 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 vulnerabilidad .

Los errores marcados como problemas de seguridad no son visibles externamente, pero eventualmente pueden volverse visibles después de evaluar o resolver el problema. Si planea enviar un parche o una prueba de conjunto de pruebas de compatibilidad (CTS) para resolver un problema de seguridad, adjúntelo al informe de errores y espere una respuesta antes de cargar el código en AOSP.

Errores de clasificación

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

Tipos de contexto

Esta tabla cubre las definiciones de contextos de seguridad de hardware y software. El contexto se puede definir por la sensibilidad de los datos que normalmente procesa o el área en la que se ejecuta. No todos los contextos de seguridad son aplicables a todos los sistemas. Esta tabla está ordenada de menos a más privilegiados.

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, aplicaciones de confianza que procesan datos que no son de confianza dentro de un entorno de espacio aislado.
Contexto no privilegiado Un entorno de ejecución típico esperado por código sin privilegios.

Por ejemplo, una aplicación de Android que se ejecuta en un dominio SELinux con el atributo untrusted_app_all .
Contexto privilegiado Un entorno de ejecución privilegiado que puede tener acceso a permisos elevados, maneja PII de múltiples usuarios y/o mantiene la integridad del sistema.

Por ejemplo, una aplicación de Android con capacidades que estarían prohibidas por el dominio untrusted_app de SELinux o con acceso a permisos privileged|signature .
Núcleo del sistema operativo Funcionalidad que:
  • es parte del núcleo
  • se ejecuta en el mismo contexto de CPU que el núcleo (por ejemplo, controladores de dispositivos)
  • tiene acceso directo a la memoria del kernel (por ejemplo, componentes de hardware en el dispositivo)
  • tiene la capacidad de cargar scripts en un componente del kernel (por ejemplo, eBPF)
  • es uno de los pocos servicios de usuario que se considera equivalente al kernel (como apexd , bpfloader , init , ueventd y vold ).
Base de hardware de confianza (THB) Componentes de hardware discretos, generalmente en el SoC, que brindan una funcionalidad crítica para los casos de uso principales del dispositivo (como bandas base celulares, DSP, GPU y procesadores ML).
Cadena del cargador de arranque Un componente que configura el dispositivo en el arranque y luego pasa el control al sistema operativo Android.
Entorno de ejecución de confianza (TEE) Un componente que está diseñado para protegerse incluso de un kernel de sistema operativo hostil (por ejemplo, TrustZone e hipervisores, como pKVM, que protegen las máquinas virtuales del kernel de sistema operativo).
Enclave seguro/Elemento seguro (SE) Un componente de hardware opcional diseñado para protegerse de todos los demás componentes del dispositivo y de ataques físicos, como se define en Introducción a Secure Elements .

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

Gravedad

La gravedad de un error generalmente refleja el daño potencial que podría ocurrir si un error se explotara con éxito. Utilice los siguientes criterios para determinar la gravedad.

Clasificación Consecuencia de una explotación exitosa
Crítico
  • Ejecución de código arbitrario en el TEE o SE
  • Eludir los mecanismos de software diseñados para evitar el mal funcionamiento de los componentes de software o hardware relacionados con la seguridad (por ejemplo, protecciones térmicas)
  • Acceso remoto a credenciales confidenciales utilizadas 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 banda base celular sin interacción del usuario (por ejemplo, aprovechando un error en el servicio de radio celular)
  • Ejecución remota de código arbitrario en un contexto privilegiado, la cadena del cargador de arranque, THB o el kernel del sistema operativo
  • Omisión remota de los requisitos de interacción del usuario en la instalación del paquete o comportamiento equivalente
  • Omisión remota de los requisitos de interacción del usuario para la configuración principal del desarrollador, la seguridad o la privacidad
  • Denegación de servicio persistente remota (permanente, que requiere volver a actualizar todo el sistema operativo o un restablecimiento de fábrica)
  • Omisión de arranque remoto seguro
  • Acceso no autorizado a datos protegidos por SE, incluido el acceso habilitado por claves débiles en SE.
Alto
  • Una omisión completa de una función de seguridad central (por ejemplo, SELinux, FBE o seccomp )
  • Un bypass general para una defensa en profundidad o tecnología de mitigación de exploits en la cadena del gestor de arranque, TEE o SE
  • Una omisión general para las protecciones del sistema operativo que revelan la memoria o el contenido de los archivos a través de los límites de la aplicación, el usuario o el perfil
  • Ataques contra un SE que resultan en una degradación a una implementación menos segura
  • Omisión de la protección del dispositivo/protección de restablecimiento de fábrica/restricciones del operador
  • Eludir los requisitos de interacción del usuario que están asegurados por el TEE
  • Vulnerabilidad criptográfica que permite ataques contra protocolos de extremo a extremo, incluidos ataques contra la seguridad de la capa de transporte (TLS) y Bluetooth (BT).
  • Acceso local a credenciales confidenciales utilizadas 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 privilegiado, la cadena del gestor de arranque, THB o el kernel del sistema operativo
  • Omisión de arranque seguro local
  • Omitir pantalla de bloqueo
  • Omisión local de los requisitos de interacción del usuario para la configuración principal del desarrollador, la seguridad o la privacidad
  • Omisión local de los requisitos de interacción del usuario en la instalación del paquete o comportamiento equivalente
  • Denegación de servicio persistente local (permanente, que requiere volver a actualizar todo el sistema operativo o restablecer los valores de fábrica)
  • Acceso remoto a datos protegidos (es decir, datos que están limitados a un contexto privilegiado)
  • Ejecución remota de código arbitrario en un contexto no privilegiado
  • Prevención remota del acceso al servicio celular o Wi-Fi sin interacción del usuario (por ejemplo, colapsar el servicio de radio celular con un paquete con formato incorrecto)
  • Omisión remota de los requisitos de interacción del usuario (acceso a funciones o datos que deben requerir la iniciación o el permiso del usuario)
  • Prevención dirigida del acceso a los servicios de emergencia
  • Transmitir información confidencial a través de un protocolo de red no seguro (por ejemplo, HTTP y Bluetooth sin cifrar) cuando el solicitante espera una transmisión segura. Tenga en cuenta que esto no se aplica al cifrado Wi-Fi (como WEP)
  • Acceso no autorizado a 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 tecnología de mitigación de exploits en un contexto privilegiado, THB o el kernel del sistema operativo
  • Una omisión general para las protecciones del sistema operativo que revelan el estado del proceso o los metadatos a través de los límites de la aplicación, el usuario o el perfil
  • Omitir el cifrado o la autenticación de Wi-Fi
  • Vulnerabilidad criptográfica en primitivas criptográficas estándar que permite filtrar texto sin formato (no primitivas utilizadas en TLS)
  • Acceso local a datos protegidos (es decir, datos que están limitados a un contexto privilegiado)
  • Ejecución de código arbitrario local en un contexto no privilegiado
  • Omisión local de los requisitos de interacción del usuario (acceso a funciones o datos que normalmente requerirían la iniciación o el permiso del usuario)
  • Acceso remoto a datos no protegidos (es decir, datos normalmente accesibles para cualquier aplicación instalada localmente)
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación de servicio de dispositivo temporal remoto (bloqueo o reinicio remoto)
Bajo
  • Un bypass general para una defensa a nivel de usuario en profundidad o tecnología de mitigación de exploits en un contexto no privilegiado
  • Omisión de un permiso de nivel de protección normal
  • Vulnerabilidad criptográfica en uso no estándar
  • Omisión general de funciones de personalización en el dispositivo, como Voice Match o Face Match
  • Documentación incorrecta que puede conducir a 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 falsa expectativa de seguridad
Impacto de seguridad insignificante (NSI)
  • Una vulnerabilidad cuyo impacto ha sido mitigado por uno o más modificadores de calificación o cambios de arquitectura específicos de la versión, de modo que la gravedad efectiva es inferior a Baja, aunque el problema de código subyacente puede permanecer.
  • Cualquier vulnerabilidad que requiera un sistema de archivos con formato incorrecto, si ese sistema de archivos siempre se adopta/cifra antes de su uso.

Modificadores de calificación

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

Razón Efecto
Requiere ejecutarse como un contexto privilegiado para ejecutar el ataque (no aplicable a TEE, SE e hipervisores como pKVM) -1 Gravedad
Los detalles específicos de la vulnerabilidad limitan el impacto del problema -1 Gravedad
Omisión de autenticación biométrica que requiere información biométrica directamente del propietario del dispositivo -1 Gravedad
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 las partes internas del dispositivo y aún es posible si el dispositivo está apagado o no se ha desbloqueado desde que se encendió -1 Gravedad
Requiere acceso físico a las partes internas del dispositivo mientras el dispositivo está encendido y se ha desbloqueado previamente -2 Gravedad
Un ataque local que requiere que se desbloquee la cadena del cargador de arranque No más alto que Bajo
Un ataque local que requiere que el modo de desarrollador o cualquier configuración de modo de desarrollador persistente esté habilitada actualmente en el dispositivo (y no es un error en el modo de desarrollador en sí). No más alto que Bajo
Si ningún dominio SELinux puede realizar la operación bajo la SEPolicy proporcionada por Google Impacto de seguridad insignificante

Local versus proximal versus remoto

Un vector de ataque remoto indica que el error se puede explotar sin instalar una aplicación o sin acceso físico a un dispositivo. Esto incluye errores que pueden desencadenarse al navegar a una página web, leer un correo electrónico, recibir un mensaje SMS o conectarse a una red hostil. A los efectos de nuestras clasificaciones de gravedad, también consideramos los vectores de ataque "proximales" como remotos. Estos incluyen errores que solo pueden ser explotados por 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 formato incorrecto. Consideramos los ataques de banda ultraancha (UWB) y basados ​​en NFC como próximos y, por lo tanto, remotos.

Los ataques locales requieren que la víctima ejecute una aplicación, ya sea instalando y ejecutando una aplicación o dando su consentimiento para ejecutar una aplicación instantánea . Los dispositivos complementarios vinculados se considerarán locales. A los efectos de las clasificaciones de gravedad, el equipo de seguridad de Android también considera los vectores de ataque físico como locales. Estos incluyen errores que solo pueden ser explotados por un atacante que tenga acceso físico al dispositivo, por ejemplo, un error en una pantalla de bloqueo o uno que requiere conectar un cable USB.

Seguridad de la red

Android asume 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 enlace (por ejemplo, el cifrado Wi-Fi) protege la comunicación entre un dispositivo y el punto de acceso al que está conectado, no hace nada para proteger los enlaces restantes en la cadena entre el dispositivo y los servidores con los que se comunica.

Por el contrario, HTTPS normalmente protege toda la comunicación de principio a fin, cifrando los datos en su origen, luego descifrándolos y verificándolos solo una vez que han llegado a su destino final. Debido a esto, las vulnerabilidades que comprometen la seguridad de la red de la capa de enlace se clasifican como menos graves que las vulnerabilidades en HTTPS/TLS: el cifrado Wi-Fi por sí solo es insuficiente para la mayoría de las comunicaciones en Internet.

Autenticación biométrica

La autenticación biométrica es un espacio desafiante, e incluso los mejores sistemas pueden ser engañados por una coincidencia cercana (consulte el Blog de desarrolladores de Android: Pantalla de bloqueo y mejoras de autenticación en Android 11 ). Estas clasificaciones de gravedad distinguen entre dos clases de ataques y pretenden reflejar el riesgo real para el usuario final.

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

La otra clase de ataques generalmente implica un instrumento de ataque de presentación (suplantación de identidad) basado en el propietario del dispositivo. A veces, esta información biométrica es relativamente fácil de obtener (por ejemplo, si la imagen de perfil de alguien en las redes sociales es suficiente para engañar a la autenticación biométrica, entonces una omisión biométrica recibiría la calificación de gravedad completa). Pero si un atacante necesitara adquirir datos biométricos directamente del propietario del dispositivo (por ejemplo, un escaneo infrarrojo de su cara), esa es una barrera 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 tapjacking, consulte la sección " Vulnerabilidad de tapjacking/superposición SYSTEM_ALERT_WINDOW en una pantalla que no es crítica para la seguridad " de la página Errores sin impacto en la seguridad de BugHunter University.

Seguridad multiusuario en Android Automotive OS

Android Automotive OS adopta un modelo de seguridad multiusuario diferente de los otros factores de forma. Cada usuario de Android está destinado a ser utilizado por una persona física diferente. Por ejemplo, se puede asignar un usuario invitado temporal a un amigo que toma prestado el vehículo del propietario del automóvil. Para adaptarse a casos de uso como este, los usuarios tienen acceso de manera predeterminada a los componentes necesarios para usar el vehículo, como la configuración de la red Wi-Fi y celular.

Componente afectado

El equipo de desarrollo responsable de solucionar el error depende del componente en el que se encuentre. Podría ser un componente central de la plataforma Android, un controlador de kernel proporcionado por un fabricante de equipos originales (OEM) o una de las aplicaciones precargadas en los dispositivos Pixel. .

El equipo de ingeniería de Android corrige los errores en el código AOSP. Los errores de baja gravedad, los errores en ciertos componentes o los errores que ya son conocidos públicamente pueden corregirse directamente en la rama principal de AOSP disponible públicamente; de lo contrario, se fijan primero en nuestros repositorios internos.

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

Notificar a los socios

Cuando se solucione 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 proporcionaremos parches. La lista de versiones compatibles con backport cambia con cada nueva versión de Android. Póngase en contacto con el fabricante de su dispositivo para obtener la lista de dispositivos compatibles.

Liberando código a AOSP

Si el error de seguridad se encuentra en un componente de AOSP, la solución se envía a AOSP después de que se lanza la OTA a los usuarios. Las soluciones para problemas de baja gravedad se pueden enviar directamente a la sucursal principal de AOSP antes de que una solución esté disponible para los dispositivos a través de una OTA.

Recibir actualizaciones de Android

Las actualizaciones del sistema Android generalmente se entregan a los dispositivos a través de paquetes de actualización OTA. Estas actualizaciones pueden provenir del OEM que produjo el dispositivo o del operador que brinda servicio al dispositivo. Las actualizaciones del dispositivo 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 píxeles que se pueden cargar lateralmente en los dispositivos.

Actualización de 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 escanea todas las aplicaciones y elimina cualquier aplicación que intente aprovechar un error de seguridad. Para las aplicaciones instaladas desde fuera de Google Play, los dispositivos con Google Play Services también pueden usar la función Verificar aplicaciones para advertir a los usuarios sobre aplicaciones que pueden ser potencialmente dañinas.

Otros recursos

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

La información de seguridad existe en los sitios para desarrolladores y código abierto de Android. Buenos lugares para comenzar:

Informes

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

,

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

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

Reportar 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 vulnerabilidad .

Los errores marcados como problemas de seguridad no son visibles externamente, pero eventualmente pueden volverse visibles después de evaluar o resolver el problema. Si planea enviar un parche o una prueba de conjunto de pruebas de compatibilidad (CTS) para resolver un problema de seguridad, adjúntelo al informe de errores y espere una respuesta antes de cargar el código en AOSP.

Errores de clasificación

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

Tipos de contexto

Esta tabla cubre las definiciones de contextos de seguridad de hardware y software. El contexto se puede definir por la sensibilidad de los datos que normalmente procesa o el área en la que se ejecuta. No todos los contextos de seguridad son aplicables a todos los sistemas. Esta tabla está ordenada de menos a más privilegiados.

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, aplicaciones de confianza que procesan datos que no son de confianza dentro de un entorno de espacio aislado.
Contexto no privilegiado Un entorno de ejecución típico esperado por código sin privilegios.

Por ejemplo, una aplicación de Android que se ejecuta en un dominio SELinux con el atributo untrusted_app_all .
Contexto privilegiado Un entorno de ejecución privilegiado que puede tener acceso a permisos elevados, maneja PII de múltiples usuarios y/o mantiene la integridad del sistema.

Por ejemplo, una aplicación de Android con capacidades que estarían prohibidas por el dominio untrusted_app de SELinux o con acceso a permisos privileged|signature .
Núcleo del sistema operativo Funcionalidad que:
  • es parte del núcleo
  • se ejecuta en el mismo contexto de CPU que el núcleo (por ejemplo, controladores de dispositivos)
  • tiene acceso directo a la memoria del kernel (por ejemplo, componentes de hardware en el dispositivo)
  • tiene la capacidad de cargar scripts en un componente del kernel (por ejemplo, eBPF)
  • es uno de los pocos servicios de usuario que se considera equivalente al kernel (como apexd , bpfloader , init , ueventd y vold ).
Base de hardware de confianza (THB) Componentes de hardware discretos, generalmente en el SoC, que brindan una funcionalidad crítica para los casos de uso principales del dispositivo (como bandas base celulares, DSP, GPU y procesadores ML).
Cadena del cargador de arranque Un componente que configura el dispositivo en el arranque y luego pasa el control al sistema operativo Android.
Entorno de ejecución de confianza (TEE) Un componente que está diseñado para protegerse incluso de un kernel de sistema operativo hostil (por ejemplo, TrustZone e hipervisores, como pKVM, que protegen las máquinas virtuales del kernel de sistema operativo).
Enclave seguro/Elemento seguro (SE) Un componente de hardware opcional diseñado para protegerse de todos los demás componentes del dispositivo y de ataques físicos, como se define en Introducción a Secure Elements .

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

Gravedad

La gravedad de un error generalmente refleja el daño potencial que podría ocurrir si un error se explotara con éxito. Utilice los siguientes criterios para determinar la gravedad.

Clasificación Consecuencia de una explotación exitosa
Crítico
  • Ejecución de código arbitrario en el TEE o SE
  • Eludir los mecanismos de software diseñados para evitar el mal funcionamiento de los componentes de software o hardware relacionados con la seguridad (por ejemplo, protecciones térmicas)
  • Acceso remoto a credenciales confidenciales utilizadas 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 banda base celular sin interacción del usuario (por ejemplo, aprovechando un error en el servicio de radio celular)
  • Ejecución remota de código arbitrario en un contexto privilegiado, la cadena del cargador de arranque, THB o el kernel del sistema operativo
  • Omisión remota de los requisitos de interacción del usuario en la instalación del paquete o comportamiento equivalente
  • Omisión remota de los requisitos de interacción del usuario para la configuración principal del desarrollador, la seguridad o la privacidad
  • Denegación de servicio persistente remota (permanente, que requiere volver a actualizar todo el sistema operativo o un restablecimiento de fábrica)
  • Omisión de arranque remoto seguro
  • Acceso no autorizado a datos protegidos por SE, incluido el acceso habilitado por claves débiles en SE.
Alto
  • Una omisión completa de una función de seguridad central (por ejemplo, SELinux, FBE o seccomp )
  • Un bypass general para una defensa en profundidad o tecnología de mitigación de exploits en la cadena del gestor de arranque, TEE o SE
  • Una omisión general para las protecciones del sistema operativo que revelan la memoria o el contenido de los archivos a través de los límites de la aplicación, el usuario o el perfil
  • Ataques contra un SE que resultan en una degradación a una implementación menos segura
  • Omisión de la protección del dispositivo/protección de restablecimiento de fábrica/restricciones del operador
  • Eludir los requisitos de interacción del usuario que están asegurados por el TEE
  • Vulnerabilidad criptográfica que permite ataques contra protocolos de extremo a extremo, incluidos ataques contra la seguridad de la capa de transporte (TLS) y Bluetooth (BT).
  • Acceso local a credenciales confidenciales utilizadas 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 privilegiado, la cadena del gestor de arranque, THB o el kernel del sistema operativo
  • Omisión de arranque seguro local
  • Omitir pantalla de bloqueo
  • Omisión local de los requisitos de interacción del usuario para la configuración principal del desarrollador, la seguridad o la privacidad
  • Omisión local de los requisitos de interacción del usuario en la instalación del paquete o comportamiento equivalente
  • Denegación de servicio persistente local (permanente, que requiere volver a actualizar todo el sistema operativo o restablecer los valores de fábrica)
  • Acceso remoto a datos protegidos (es decir, datos que están limitados a un contexto privilegiado)
  • Ejecución remota de código arbitrario en un contexto no privilegiado
  • Prevención remota del acceso al servicio celular o Wi-Fi sin interacción del usuario (por ejemplo, colapsar el servicio de radio celular con un paquete con formato incorrecto)
  • Omisión remota de los requisitos de interacción del usuario (acceso a funciones o datos que deben requerir la iniciación o el permiso del usuario)
  • Prevención dirigida del acceso a los servicios de emergencia
  • Transmitir información confidencial a través de un protocolo de red no seguro (por ejemplo, HTTP y Bluetooth sin cifrar) cuando el solicitante espera una transmisión segura. Tenga en cuenta que esto no se aplica al cifrado Wi-Fi (como WEP)
  • Acceso no autorizado a 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 tecnología de mitigación de exploits en un contexto privilegiado, THB o el kernel del sistema operativo
  • Una omisión general para las protecciones del sistema operativo que revelan el estado del proceso o los metadatos a través de los límites de la aplicación, el usuario o el perfil
  • Omitir el cifrado o la autenticación de Wi-Fi
  • Vulnerabilidad criptográfica en primitivas criptográficas estándar que permite filtrar texto sin formato (no primitivas utilizadas en TLS)
  • Acceso local a datos protegidos (es decir, datos que están limitados a un contexto privilegiado)
  • Ejecución de código arbitrario local en un contexto no privilegiado
  • Omisión local de los requisitos de interacción del usuario (acceso a funciones o datos que normalmente requerirían la iniciación o el permiso del usuario)
  • Acceso remoto a datos no protegidos (es decir, datos normalmente accesibles para cualquier aplicación instalada localmente)
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación de servicio de dispositivo temporal remoto (bloqueo o reinicio remoto)
Bajo
  • Un bypass general para una defensa a nivel de usuario en profundidad o tecnología de mitigación de exploits en un contexto no privilegiado
  • Omisión de un permiso de nivel de protección normal
  • Vulnerabilidad criptográfica en uso no estándar
  • Omisión general de funciones de personalización en el dispositivo, como Voice Match o Face Match
  • Documentación incorrecta que puede conducir a 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 falsa expectativa de seguridad
Impacto de seguridad insignificante (NSI)
  • Una vulnerabilidad cuyo impacto ha sido mitigado por uno o más modificadores de calificación o cambios de arquitectura específicos de la versión, de modo que la gravedad efectiva es inferior a Baja, aunque el problema de código subyacente puede permanecer.
  • Cualquier vulnerabilidad que requiera un sistema de archivos con formato incorrecto, si ese sistema de archivos siempre se adopta/cifra antes de su uso.

Modificadores de calificación

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

Razón Efecto
Requiere ejecutarse como un contexto privilegiado para ejecutar el ataque (no aplicable a TEE, SE e hipervisores como pKVM) -1 Gravedad
Los detalles específicos de la vulnerabilidad limitan el impacto del problema -1 Gravedad
Omisión de autenticación biométrica que requiere información biométrica directamente del propietario del dispositivo -1 Gravedad
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 las partes internas del dispositivo y aún es posible si el dispositivo está apagado o no se ha desbloqueado desde que se encendió -1 Gravedad
Requiere acceso físico a las partes internas del dispositivo mientras el dispositivo está encendido y se ha desbloqueado previamente -2 Gravedad
Un ataque local que requiere que se desbloquee la cadena del cargador de arranque No más alto que Bajo
Un ataque local que requiere que el modo de desarrollador o cualquier configuración de modo de desarrollador persistente esté habilitada actualmente en el dispositivo (y no es un error en el modo de desarrollador en sí). No más alto que Bajo
Si ningún dominio SELinux puede realizar la operación bajo la SEPolicy proporcionada por Google Impacto de seguridad insignificante

Local versus proximal versus remoto

Un vector de ataque remoto indica que el error se puede explotar sin instalar una aplicación o sin acceso físico a un dispositivo. Esto incluye errores que pueden desencadenarse al navegar a una página web, leer un correo electrónico, recibir un mensaje SMS o conectarse a una red hostil. A los efectos de nuestras clasificaciones de gravedad, también consideramos los vectores de ataque "proximales" como remotos. Estos incluyen errores que solo pueden ser explotados por 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 formato incorrecto. Consideramos los ataques de banda ultraancha (UWB) y basados ​​en NFC como próximos y, por lo tanto, remotos.

Los ataques locales requieren que la víctima ejecute una aplicación, ya sea instalando y ejecutando una aplicación o dando su consentimiento para ejecutar una aplicación instantánea . Los dispositivos complementarios vinculados se considerarán locales. A los efectos de las clasificaciones de gravedad, el equipo de seguridad de Android también considera los vectores de ataque físico como locales. Estos incluyen errores que solo pueden ser explotados por un atacante que tenga acceso físico al dispositivo, por ejemplo, un error en una pantalla de bloqueo o uno que requiere conectar un cable USB.

Seguridad de la red

Android asume 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 enlace (por ejemplo, el cifrado Wi-Fi) protege la comunicación entre un dispositivo y el punto de acceso al que está conectado, no hace nada para proteger los enlaces restantes en la cadena entre el dispositivo y los servidores con los que se comunica.

Por el contrario, HTTPS normalmente protege toda la comunicación de principio a fin, cifrando los datos en su origen, luego descifrándolos y verificándolos solo una vez que han llegado a su destino final. Debido a esto, las vulnerabilidades que comprometen la seguridad de la red de la capa de enlace se clasifican como menos graves que las vulnerabilidades en HTTPS/TLS: el cifrado Wi-Fi por sí solo es insuficiente para la mayoría de las comunicaciones en Internet.

Autenticación biométrica

La autenticación biométrica es un espacio desafiante, e incluso los mejores sistemas pueden ser engañados por una coincidencia cercana (consulte el Blog de desarrolladores de Android: Pantalla de bloqueo y mejoras de autenticación en Android 11 ). Estas clasificaciones de gravedad distinguen entre dos clases de ataques y pretenden reflejar el riesgo real para el usuario final.

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

La otra clase de ataques generalmente implica un instrumento de ataque de presentación (suplantación de identidad) basado en el propietario del dispositivo. A veces, esta información biométrica es relativamente fácil de obtener (por ejemplo, si la imagen de perfil de alguien en las redes sociales es suficiente para engañar a la autenticación biométrica, entonces una omisión biométrica recibiría la calificación de gravedad completa). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.

SYSTEM_ALERT_WINDOW and Tapjacking

For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.

Multi-user security in Android Automotive OS

Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.

Affected component

The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.

Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.

The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.

Notifying partners

When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.

Releasing code to AOSP

If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.

Receiving Android updates

Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.

Updating Google services

In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.

Other resources

Information for Android app developers: https://developer.android.com

Security information exists throughout the Android Open Source and Developer sites. Good places to start:

Reports

Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.