Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Recursos y actualizaciones 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 una investigación interna y también responde a los errores informados por terceros. Fuente de los fallos externos incluyen cuestiones informaron a través de la plantilla de problemas de seguridad de Android , publicado y publicada previamente la investigación académica, abiertas mantenedores del proyecto fuente de aguas arriba, las notificaciones de nuestros socios fabricantes de dispositivos, y públicamente divulgados temas publicados en blogs o redes sociales.

Informar problemas de seguridad

Cualquier desarrollador, usuario de Android, o el investigador de seguridad pueden notificar al equipo de seguridad de Android de posibles problemas de seguridad a través del formulario de notificación vulnerabilidad de seguridad .

Los errores marcados como problemas de seguridad no son visibles externamente, pero es posible que eventualmente se hagan visibles después de que se evalúe o resuelva el problema. Si planea enviar un parche o una prueba de Compatibility Test Suite (CTS) para resolver un problema de seguridad, adjúntelo al informe de error y espere una respuesta antes de cargar el código en AOSP.

Detección de errores

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 le 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 por el área en la que se ejecuta. No todos los contextos de seguridad son aplicables 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 donde solo se proporcionan los permisos más mínimos.

Por ejemplo, aplicaciones "sandboxes" para procesar datos que no son de confianza sin permitir el acceso al sistema subyacente.
Contexto sin privilegios Un entorno de ejecución típico esperado por código sin privilegios.

Por ejemplo, una aplicación para Android que se ejecuta en un dominio de SELinux con el untrusted_app_all atributo.
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 para Android con capacidades que estaría prohibido por el SELinux untrusted_app dominio o con el acceso a los privileged|signature permisos.
Base informática confiable (TCB) La funcionalidad que forma parte del kernel, se ejecuta en el mismo contexto de CPU que el kernel (como los controladores de dispositivo), tiene acceso directo a la memoria del kernel (como los componentes de hardware en el dispositivo), tiene la capacidad de cargar scripts en un componente del kernel ( por ejemplo, EBPF), los procesadores de comunicación, o es uno de un puñado de servicios de usuario que se considera kernel equivalente: apexd , bpfloader , init , ueventd , y vold .
Cadena de cargador de arranque Un componente que configura el dispositivo al arrancar y luego pasa el control al sistema operativo Android.
Entorno de ejecución confiable (TEE) Un componente que está diseñado para protegerse incluso de un kernel hostil (por ejemplo, TrustZone e Hypervisor).
Enclave seguro / Elemento seguro (SE) Un componente opcional de hardware diseñado para ser protegido de todos los demás componentes en el dispositivo y de ataque físico, tal como se define en Introducción a elementos seguros .

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

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
  • Acceso no autorizado a datos protegidos por el SE
  • Ejecución de código arbitrario en el TEE o SE
  • Ejecución remota de código arbitrario en un contexto privilegiado, la cadena del cargador de arranque o la TCB
  • Denegación de servicio persistente remota (permanente o que requiere la actualización de todo el sistema operativo o un restablecimiento de fábrica)
  • 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 cualquier configuración de desarrollador, seguridad o privacidad
  • Omisión de arranque seguro remoto
  • Omisión de mecanismos diseñados para evitar que los componentes de hardware o software relacionados con la seguridad funcionen mal (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)
Elevado
  • Omisión de arranque seguro local
  • Un desvío completo de una característica de seguridad central (como SELinux, FDE o seccomp)
  • Ejecución remota de código arbitrario en un contexto sin privilegios
  • Ejecución de código arbitrario local en un contexto privilegiado, la cadena del cargador de arranque o la TCB
  • Acceso no autorizado a los datos protegidos por el TEE
  • Ataques contra un SE que dan como resultado la degradación a una implementación menos segura
  • Omisión local de los requisitos de interacción del usuario en la instalación del paquete o comportamiento equivalente
  • Acceso remoto a datos protegidos (datos que se limitan a un contexto privilegiado)
  • Denegación de servicio persistente local (permanente o que requiere la actualización de todo el sistema operativo o restablecimiento de fábrica)
  • Omisión remota de los requisitos de interacción del usuario (acceso a la funcionalidad o datos que normalmente requerirían la iniciación del usuario o el permiso del usuario)
  • Transmitir información confidencial a través de un protocolo de red inseguro (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 de Wi-Fi, como WEP)
  • Un desvío general para una defensa en profundidad o una tecnología de mitigación de explotación en la cadena del cargador de arranque, TEE o SE
  • Una omisión general para las protecciones del sistema operativo que aíslan los datos de las aplicaciones o los perfiles de usuario entre sí
  • Omisión local de los requisitos de interacción del usuario para cualquier configuración de desarrollador, seguridad o privacidad
  • 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).
  • Omisión de pantalla de bloqueo
  • Omisión de la protección del dispositivo / protección de restablecimiento de fábrica / restricciones del operador
  • Prevención selectiva del acceso a los servicios de emergencia
  • Omisión de los requisitos de interacción del usuario que están asegurados por el TEE
  • Prevención remota del acceso al servicio celular sin interacción del usuario (por ejemplo, colapso del servicio de radio celular con un paquete con formato incorrecto)
  • Acceso local a credenciales confidenciales utilizadas para la autenticación de servicios remotos (por ejemplo, contraseñas de cuentas o tokens de portador)
Moderar
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación de servicio del dispositivo temporal remoto (bloqueo o reinicio remoto)
  • Ejecución de código arbitrario local en un contexto sin privilegios
  • Un bypass general para una defensa en profundidad o explotar la tecnología de mitigación en un contexto privilegiado o el TCB
  • Omisión de restricciones en un proceso restringido
  • Acceso remoto a datos desprotegidos (datos normalmente accesibles a cualquier aplicación instalada localmente)
  • Acceso local a datos protegidos (datos que se limitan a un contexto privilegiado)
  • Omisión local de los requisitos de interacción del usuario (acceso a la funcionalidad o datos que normalmente requerirían la iniciación del usuario o el permiso del usuario)
  • Vulnerabilidad criptográfica en primitivas criptográficas estándar que permite la filtración de texto sin formato (no las primitivas utilizadas en TLS)
  • Eludir el cifrado o la autenticación de Wi-Fi
Bajo
  • Ejecución de código arbitrario local en un contexto restringido
  • Vulnerabilidad criptográfica en uso no estándar
  • Un desvío general para una defensa a nivel de usuario en profundidad o aprovechar la tecnología de mitigación en un contexto sin privilegios
  • Documentación incorrecta que puede dar lugar a un malentendido relacionado con la seguridad con defectos de código posteriores
  • By-pass general de la personalización en el dispositivo cuenta como Partido de voz o de ajuste de cara
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 del código subyacente puede permanecer.
  • Cualquier vulnerabilidad que requiere un sistema de archivos con formato incorrecto, si ese sistema de archivos siempre se adoptó / encriptados 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 -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 ha sido 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 del modo de desarrollador persistente esté habilitado 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 de SELinux puede realizar la operación bajo la política SEP proporcionada por Google Impacto de seguridad insignificante

Local versus proximal versus remoto

Un vector de ataque remoto indica que el error puede explotarse 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 calificaciones de gravedad, también consideramos los vectores de ataque "proximales" como remotos. Estos incluyen errores que solo pueden ser explotados por un atacante que se encuentra físicamente cerca del dispositivo objetivo, por ejemplo, un error que requiere el envío de paquetes Wi-Fi o Bluetooth mal formados. Consideramos que los ataques basados ​​en NFC y de banda ultra ancha (UWB) son proximales y, por lo tanto, remotos.

Ataques locales requieren que la víctima para ejecutar una aplicación, ya sea instalando y ejecutando una aplicación o al consentir ejecutar una instantánea de aplicaciones . A los efectos de las clasificaciones de gravedad, también consideramos los vectores de ataque físico como locales. Estos incluyen errores que solo pueden ser explotados por un atacante que tiene acceso físico al dispositivo, por ejemplo, un error en una pantalla de bloqueo o uno que requiere enchufar un cable USB. Tenga en cuenta que los ataques que requieren una conexión USB tienen la misma gravedad independientemente de si el dispositivo debe estar desbloqueado o no; Es común que los dispositivos se desbloqueen mientras están conectados a 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 de Wi-Fi) protege la comunicación entre un dispositivo y el punto de acceso al que está conectado, no hace nada para asegurar los enlaces restantes en la cadena entre el dispositivo y los servidores con los que se está comunicando.

Por el contrario, HTTPS generalmente protege toda la comunicación de un extremo a otro, encriptando los datos en su origen, luego descifrándolos y verificándolos solo una vez que llegan 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 de 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 puede ser engañado por un corto partido (ver Desarrolladores de Android Blog: mejoras Lockscreen y autenticación en Android 11 ). Estas clasificaciones de gravedad distinguen entre dos clases de ataques y están destinadas a 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 afecta a un mayor número 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 imagen de perfil de alguien en las redes sociales es suficiente para engañar a la autenticación biométrica, entonces un bypass biométrico recibiría la calificación de gravedad completa). Pero si un atacante necesita adquirir datos biométricos directamente del propietario del dispositivo (por ejemplo, un escaneo infrarrojo de su rostro), 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 acerca de nuestras políticas con respecto SYSTEM_ALERT_WINDOW y tapjacking, consulte la "superposición SYSTEM_ALERT_WINDOW vulnerabilidad Tapjacking / sobre una base no-crítica de seguridad de pantalla" de la Universidad de BugHunter insectos sin afectar la seguridad página.

Componente afectado

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

Los errores en el código AOSP los corrige el equipo de ingeniería de Android. Los errores de baja gravedad, los errores en ciertos componentes o los errores que ya se conocen públicamente pueden corregirse directamente en la rama maestra de AOSP disponible públicamente; de lo contrario, primero se fijan 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 kernel requiere una actualización de firmware por aire (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 soluciona 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. Comuníquese con el fabricante de su dispositivo para obtener la lista de dispositivos compatibles.

Liberar código a AOSP

Si el error de seguridad está en un componente de AOSP, la solución se envía a AOSP después de que la OTA se lanza a los usuarios. Las correcciones para problemas de baja gravedad pueden enviarse directamente a la rama maestra de AOSP antes de que haya una corrección disponible para los dispositivos a través de una OTA.

Recibir actualizaciones de Android

Las actualizaciones del sistema Android generalmente se envían 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 pueden ser dispositivos de carga lateral.

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 existen otras formas de proteger a los usuarios. Por ejemplo, Google Play analiza 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 los servicios de Play también pueden usar la Verificar aplicaciones función para advertir a los usuarios acerca de las aplicaciones que pueden ser potencialmente dañinos.

Otros recursos

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

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

Informes

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