Actualizaciones y recursos de seguridad

El equipo de seguridad de Android es responsable de administrar las vulnerabilidades de seguridad que se descubren en la plataforma de Android y en 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 previas a la publicación, 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 se hagan 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 al AOSP.

Clasifica errores

La primera tarea para abordar una vulnerabilidad de seguridad es identificar la gravedad del error y el componente de Android afectado. La gravedad determina la prioridad del problema, y el componente determina quién corrige el error, a quién se notifica y cómo se implementa la corrección para 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 del tipo
Contexto restringido Es 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 Es 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 Es un entorno de ejecución privilegiado que puede tener acceso a permisos elevados, controlar varios datos personales del usuario o mantener la integridad del sistema.

Por ejemplo, una app para Android con capacidades que estarían prohibidas por el dominio untrusted_app de SELinux o con acceso a permisos de privileged|signature.
Kernel del SO Funcionalidad que:
  • 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 del usuario que se consideran equivalentes al kernel (como apexd, bpfloader, init, ueventd y vold).
Base de hardware de confianza (THB) Componentes de hardware discretos, generalmente en el SoC, que proporcionan funcionalidad crítica para los casos de uso principales del dispositivo (como bandas base celulares, DSP, GPU y procesadores de AA).
Cadena del 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 protegerse incluso de un kernel del SO hostil (por ejemplo, TrustZone e hipervisores, como pKVM, que protegen las máquinas virtuales del kernel del SO).
Secure Enclave o Elemento seguro (SE) Es 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 la Introducción a los elementos seguros.

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 se explota correctamente. Usa los siguientes criterios para determinar la gravedad.

Clasificación Consecuencia de la explotación exitosa
Crítica
  • Ejecución de código arbitrario en el TEE o el SE
  • Elusión de mecanismos de software diseñados para evitar el mal funcionamiento de componentes de software o hardware relacionados con la seguridad (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 en el 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 del cargador 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 comportamiento equivalente
  • Omisión remota de los requisitos de interacción del usuario para la configuración principal de desarrollador, seguridad o privacidad
  • Denegación de servicio persistente remota (permanente, requiere volver a escribir la memoria flash de 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
  • Se omite por completo 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 del cargador de arranque, el TEE o el SE
  • Una elusión general de las protecciones del sistema operativo que revela el contenido de la memoria o los archivos a través de los límites de la app, el usuario o el perfil
  • Ataques contra un SE que provocan una degradación a una implementación menos segura
  • Realizar un pivote desde un firmware de metal desnudo comprometido y accesible de forma remota (por ejemplo, banda base, procesador de comunicaciones [CP]) al kernel del procesador de aplicaciones (AP) o mecanismos de omisión diseñados para aislar el firmware de metal desnudo del kernel del AP
  • Elusión de la protección del dispositivo, la protección contra restablecimiento de la configuración de fábrica (en Android 15 y versiones posteriores) o las restricciones del operador
  • Omisión de los requisitos de interacción del usuario protegidos 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 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 privilegiado, la cadena del cargador de arranque, THB o el kernel del SO
  • Omisión local del inicio seguro
  • Omisión de la pantalla de bloqueo
  • Omisión local de los requisitos de interacción del usuario para la configuración principal de desarrollador, seguridad o privacidad
  • Omisión local de los requisitos de interacción del usuario en la instalación de paquetes o comportamiento equivalente
  • Denegación local persistente del servicio (permanente, requiere volver a escribir la memoria flash de 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
  • Denegación de servicio remota para el servicio de datos móviles o Wi-Fi que persiste hasta la intervención del usuario, activada sin interacción del usuario (por ejemplo, una falla del servicio de radio de datos móviles con un paquete con formato incorrecto que no se recupera automáticamente y requiere un reinicio manual o del dispositivo).
  • 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 segmentada del acceso a los servicios de emergencia
  • Transmitir información sensible a través de un protocolo de red inseguro (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 (por ejemplo, WEP).
  • Acceso no autorizado a los datos protegidos por el TEE, incluido el acceso habilitado por claves débiles en el TEE
Moderado
  • Una vulnerabilidad que permite eludir de forma general una defensa en profundidad o una tecnología de mitigación de exploits en un contexto privilegiado, THB o el kernel del SO
  • Una elusión general de las protecciones del sistema operativo que revela el estado del proceso o los metadatos en los límites de la app, el usuario o el perfil
  • Eludir la encriptación o la autenticación de Wi-Fi
  • Vulnerabilidad criptográfica en primitivas criptográficas estándar que permite la filtración de texto sin formato (no son primitivas que se usan 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 la funcionalidad o los datos que normalmente requerirían 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 localmente)
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación remota temporal del servicio del dispositivo (bloqueo o reinicio remotos)
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 con un nivel de protección normal
  • Vulnerabilidad criptográfica en un uso no estándar
  • Bypass 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 insignificante (NSI)
  • Una vulnerabilidad cuyo impacto se mitigó con uno o más modificadores de clasificación o cambios en la arquitectura específicos de la versión, de modo que la gravedad efectiva sea inferior a Baja, aunque el problema subyacente del código puede permanecer
  • Cualquier vulnerabilidad que requiera un sistema de archivos con formato incorrecto, si ese sistema de archivos siempre se adopta o encripta antes de usarse
  • Denegación local temporal del servicio, como cuando la condición se puede resolver reiniciando el dispositivo o desinstalando la app que activó el problema.

Modificadores de gravedad

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 privilegiado para ejecutar el ataque (no aplicable al TEE, al SE ni a los hipervisores, como pKVM) -1 de gravedad
Los detalles específicos de la vulnerabilidad limitan el impacto del problema -1 de gravedad
Omisión de la autenticación biométrica que requiere información biométrica directamente del propietario del dispositivo -1 de 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 mayor
Requiere acceso físico a los componentes internos del dispositivo y sigue siendo posible si el dispositivo está apagado o no se desbloqueó desde que se encendió. -1 de gravedad
Requiere acceso físico a los componentes internos del dispositivo mientras está encendido y se desbloqueó anteriormente. -2 de gravedad
Un ataque local que requiere que se desbloquee la cadena del bootloader No debe ser superior a la configuración Baja.
Un ataque local que requiere que el Modo de desarrollador o cualquier configuración persistente del modo de desarrollador estén habilitados en el dispositivo (y no sea un error del Modo de desarrollador en sí). No debe ser superior a la configuración Baja.
Si ningún dominio de SELinux puede realizar la operación según la SEPolicy proporcionada por Google Impacto en la seguridad insignificante

Local, proximal y remota

Un vector de ataque remoto indica que el error se puede aprovechar sin instalar una app o 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 se encuentre físicamente cerca del dispositivo de destino, por ejemplo, un error que requiere el envío de paquetes Wi-Fi o Bluetooth con formato incorrecto. Consideramos que los ataques basados en banda ultraancha (UWB) y 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 ocurrir a través de una app maliciosa que la víctima instaló o una app instantánea que aceptó ejecutar.

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 para identificar el otro dispositivo con el que se está vinculando (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 tiene acceso físico al dispositivo, por ejemplo, un error en la pantalla de bloqueo o uno que requiere conectar un cable USB. Dado que es común que los dispositivos estén desbloqueados mientras están conectados a un puerto USB, los ataques que requieren una conexión USB tienen la misma gravedad, independientemente de si se requiere que el dispositivo esté desbloqueado o no.

Seguridad de red

Android supone que todas las redes son hostiles y podrían inyectar ataques o espiar 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.

En cambio, HTTPS suele proteger toda la comunicación de extremo a extremo, ya que encripta los datos en su origen y, luego, los desencripta y verifica solo una vez que llegan a su destino final. Por este motivo, las vulnerabilidades que comprometen la seguridad de la red de capa de vínculo se consideran menos graves que las vulnerabilidades en HTTPS/TLS: el cifrado de Wi-Fi por sí solo no es suficiente para la mayoría de las comunicaciones en Internet.

Autenticación biométrica

La autenticación biométrica es un espacio desafiante, y hasta los mejores sistemas pueden ser engañados por una coincidencia cercana (consulta Blog para desarrolladores de Android: Lockscreen and authentication improvements in Android 11). Estas calificaciones 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 forma 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 según 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 podría afectar 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 involucra un instrumento de ataque de presentación (suplantació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, 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 rostro), esa sería 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 relacionadas con SYSTEM_ALERT_WINDOW y el tapjacking, consulta la sección "Vulnerabilidad de tapjacking o superposición de 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 el SO Android Automotive

SO Android Automotive adopta un modelo de seguridad multiusuario diferente de los demás factores de forma. Cada usuario de Android debe ser una persona física diferente. Por ejemplo, se le puede asignar un usuario invitado temporal a un amigo que le pide prestado el vehículo al propietario. Para adaptarse a 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 encuentre. Puede ser un componente central de la plataforma de Android, un controlador del kernel proporcionado por un fabricante de equipos originales (OEM) o una de las apps precargadas en los dispositivos Pixel.

El equipo de ingeniería de Android corrige los errores en el código del AOSP 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, 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 corrige una vulnerabilidad de seguridad en AOSP en un Boletín de seguridad de Android, notificamos a los socios de Android los detalles del problema y proporcionamos parches. La lista de versiones compatibles con la retroportabilidad cambia con cada nueva versión de Android. Comunícate con el fabricante del dispositivo para obtener la lista de dispositivos compatibles.

Lanzamiento del código al AOSP

Si el error de seguridad se encuentra en un componente del AOSP, la corrección se envía al AOSP después de que se lanza la OTA para los usuarios.

Recibe 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 de forma local a los dispositivos.

Actualiza los servicios de Google

Además de proporcionar parches para los errores de seguridad, el equipo de seguridad de Android revisa los errores de seguridad para determinar si existen 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 Servicios de Google Play también pueden usar la función Verificar aplicaciones para advertir a los usuarios sobre las apps que podrían 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 para desarrolladores. Buenos lugares para comenzar:

Informes

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