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 detecta vulnerabilidades de seguridad a través de investigaciones internas y también responde a errores informados por terceros. Las fuentes de errores externos incluyen los problemas informados mediante la formulario de vulnerabilidades, investigación académica publicada y prepublicada, encargados de mantenimiento de proyectos de código abierto ascendentes notificaciones de nuestros socios fabricantes de dispositivos y los problemas divulgados públicamente en los blogs o las redes sociales.

Informa 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 mediante el Formulario de vulnerabilidad.

Los errores marcados como problemas de seguridad no son visibles de forma externa, pero es posible que, con el tiempo, se publiquen. visible después de que el problema se evalúe o se resuelva. Si planeas enviar un parche o Prueba el Conjunto de pruebas de compatibilidad (CTS) para resolver un problema de seguridad; adjúntala al error y esperar una respuesta antes de subir el código al AOSP.

Clasificación de errores

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

Tipos de contexto

En esta tabla, se abordan las definiciones de los contextos de seguridad de hardware y software. El contexto puede puede definirse según la sensibilidad de los datos que suele procesar o el área en la que se ejecutan. No los contextos de seguridad son aplicables a todos los sistemas. Esta tabla está ordenada de menor a mayor privilegiadas.

Tipo de contexto Definición de tipo
Contexto restringido Es un entorno de ejecución restringido en el que solo se otorga la menor cantidad de permisos. que se proporcionan.

Por ejemplo, aplicaciones confiables que procesan datos no confiables dentro de en un entorno de nube.
Contexto sin privilegios Un entorno de ejecución típico que espera un código sin privilegios.

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

Por ejemplo, una aplicación para Android con capacidades que estarían prohibidas por la dominio untrusted_app de SELinux o con acceso a Permisos privileged|signature.
Kernel del SO Funciones que:
  • es parte del kernel
  • Se ejecuta en el mismo contexto de CPU que el kernel (por ejemplo, controladores de dispositivos).
  • Tiene acceso directo a la memoria del kernel (por ejemplo, los componentes de hardware en el dispositivo).
  • Tiene la capacidad de cargar secuencias de comandos en un componente de kernel (por ejemplo, eBPF).
  • es uno de los pocos servicios de usuario que se consideran equivalentes de kernel (como apexd, bpfloader, init y ueventd y vold).
Base de hardware confiable (THB) Componentes de hardware discretos, generalmente en el SoC, que proporcionan funciones fundamentales a los casos de uso principales del dispositivo (como bandas base móviles, DSP, GPU y AA) o procesadores).
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) Es un componente que está diseñado para tener protección incluso contra el kernel de un SO hostil (por ejemplo, TrustZone y hipervisores, como la pKVM, que protegen las máquinas virtuales del SO kernel).
Enclave seguro / Elemento seguro (SE) Es un componente de hardware opcional diseñado para protegerse de todos los demás componentes de la dispositivo y de un ataque físico, como se define en Introducción a los Elementos seguros.

Esto incluye el chip Titan-M, que está presente en algunos dispositivos Android.

Gravedad

La gravedad de un error por lo general refleja el daño que podría ocurrir si se tratara de se explote con éxito. Usa los siguientes criterios para determinar la gravedad.

Rating Consecuencia de la explotación exitosa
Fundamentales
  • Ejecución de código arbitrario en el TEE o SE
  • Omitir mecanismos de software diseñados para prevenir software o hardware relacionados con la seguridad componentes contra el mal funcionamiento (por ejemplo, protecciones térmicas)
  • Acceso remoto a credenciales sensibles usadas para la autenticación de servicios remotos (para como contraseñas de cuentas o tokens del portador)
  • Ejecución remota de código arbitrario dentro del contexto de banda base móvil sin necesidad de un usuario interacción (por ejemplo, explotar un error en el servicio de radio de telefonía celular)
  • Ejecución remota de código arbitrario en un contexto con privilegios, la cadena del bootloader, THB o el kernel del SO
  • Omisión remota de los requisitos de interacción del usuario en la instalación del paquete o equivalente comportamiento
  • Omisión remota de los requisitos de interacción del usuario para el desarrollador principal, la seguridad o configuración de privacidad
  • Denegación del servicio persistente remota (permanente, lo que requiere volver a escribir toda la el sistema operativo o si restableces la configuración de fábrica)
  • Omisión de inicio seguro remoto
  • Acceso no autorizado a los datos protegidos por el SE, incluido el acceso habilitado por claves débiles en el SE.
Alta
  • Una omisión completa de una función de seguridad principal (por ejemplo, SELinux, FBE o seccomp)
  • Una evasión general para una defensa en profundidad o explotar la tecnología de mitigación en el cadena de bootloader, TEE o SE
  • Una omisión general de las protecciones del sistema operativo que revelan el contenido de la memoria o los archivos más allá de los límites de la app, el usuario o el perfil
  • Ataques contra un ingeniero de ventas que tienen como resultado un cambio a una implementación menos segura
  • Pivotar desde firmware Bare Metal comprometido y accesible de forma remota (p.ej., banda base, CP/Procesador de comunicación) en el kernel del Procesador de aplicaciones (AP) o la derivación mecanismos diseñados para aislar el firmware de Bare Metal del kernel AP.
  • Omisión de la protección del dispositivo/la protección contra el restablecimiento de la configuración de fábrica/las restricciones del operador
  • Se omiten los requisitos de interacción del usuario que cuentan con la protección del 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 confidenciales usadas para la autenticación del servicio remoto (para como contraseñas de cuentas o tokens del 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 de inicio seguro local
  • Omisión de la pantalla de bloqueo
  • Omisión local de los requisitos de interacción con los usuarios para el desarrollador, la seguridad o la privacidad principales Configuración
  • Omisión local de los requisitos de interacción del usuario en la instalación del paquete o equivalente comportamiento
  • Denegación del servicio persistente local (permanente, que requiere el reinicio de toda la el sistema operativo o el restablecimiento de la configuración de fábrica).
  • acceso remoto a datos protegidos (es decir, datos que se limitan a un contexto)
  • Ejecución remota de código arbitrario en un contexto sin privilegios
  • Prevención remota del acceso a datos móviles o Wi-Fi sin interacción del usuario (para ejemplo, lo que falla el servicio de radio móvil con un paquete con formato incorrecto)
  • Omisión remota de los requisitos de interacción del usuario (acceso a funciones o datos que debe requerir la iniciación o el permiso del usuario)
  • Prevención específica del acceso a 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. Nota que no se aplica a la encriptación 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
  • Una evasión general para una defensa en profundidad o explotar la tecnología de mitigación en una contexto privilegiado, THB o el kernel del SO
  • Una evasión general para las protecciones del sistema operativo que revelan el estado o metadatos sobre los límites de la app, el usuario o el perfil
  • Omisión de la encriptación o autenticación de Wi-Fi
  • Vulnerabilidad criptográfica en primitivas criptográficas que permiten la filtración texto simple (no primitivas que se usan 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 sin privilegios
  • Omisión local de los requisitos de interacción del usuario (acceso a funciones o datos que normalmente requeriría la iniciación o el permiso del usuario)
  • Acceso remoto a datos desprotegidos (es decir, datos a los que normalmente se puede acceder de forma app instalada)
  • Ejecución remota de código arbitrario en un contexto restringido
  • Denegación de servicio temporal del dispositivo remoto (bloqueo o reinicio remoto)
Baja
  • Una evasión general para la defensa en profundidad a nivel del usuario o la tecnología de mitigación de ataques en un contexto sin privilegios
  • Evasión de una normal Nivel de protección permiso
  • Vulnerabilidad criptográfica en un uso no estándar
  • Omite de forma general las funciones de personalización integradas en el dispositivo, como las siguientes: 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 un expectativa de seguridad
Impacto insignificante de la seguridad (NSI)
  • Una vulnerabilidad cuyo impacto fue mitigado por uno o más modificadores de calificación o de la arquitectura específica de la versión, de modo que la gravedad efectiva sea inferior a Baja aunque el problema del código subyacente puede permanecer
  • Cualquier vulnerabilidad que requiera un sistema de archivos con formato incorrecto adopted/encrypted antes de usarlos.
  • Denegación temporal del servicio local (por ejemplo, cuando se puede resolver la condición mediante un reinicio o una desinstalación en el dispositivo) la app que se activa.

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.

Motivo Efecto
Requiere ejecutarse como un contexto con privilegios para ejecutar el ataque (no aplicable a TEE, SE, e hipervisores, como la pKVM) -1 gravedad
Los detalles específicos de la vulnerabilidad limitan el impacto del problema -1 gravedad
Derivación de autenticación biométrica que requiere información biométrica directamente desde el propietario del dispositivo -1 gravedad
Las configuraciones del compilador o 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 la parte interna del dispositivo y es posible si el dispositivo está apagado o no se desbloqueó desde que se encendió -1 gravedad
Requiere acceso físico a la parte interna del dispositivo mientras este esté encendido y antes lo haya hecho se desbloqueó -2 Gravedad
Un ataque local que requiere que se desbloquee la cadena del bootloader No superior a Bajo
Un ataque local que requiere el modo de desarrollador o cualquier configuración persistente del modo de desarrollador para debe estar habilitado actualmente 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 insignificante de la seguridad

Local versus proximal o remoto

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 pueden desencadenarse si navegas a un leer un correo electrónico, recibir un mensaje SMS o conectarse a una red hostil.

Los vectores de ataque próximos se consideran remotos. Entre ellas, se incluyen los errores que solo se pueden explotar por un atacante que está físicamente cerca del dispositivo objetivo, por ejemplo, un error que requiere enviar paquetes de Wi-Fi o Bluetooth con errores de formato. Consideramos los sistemas de banda ultraancha (UWB) y NFC los ataques como proximales y, por lo tanto, remotos.

Los ataques locales requieren que el atacante tenga acceso previo a la víctima. En una situación hipotética, ejemplo de solo software, podría ser a través de una aplicación maliciosa que la víctima instaló o una App instantánea que tengan dieron su consentimiento para ejecutarse.

Los dispositivos sincronizados correctamente (como los dispositivos complementarios de Bluetooth) se consideran locales. Mié hacer una distinción entre un dispositivo vinculado y un dispositivo que participa en una vinculación de tu flujo de trabajo.

  • Errores que degradan la capacidad del usuario para identificar el otro dispositivo con el que se está sincronizando (es decir, autenticación) se consideran proximales y, por lo tanto, remotas.
  • Los errores que ocurren durante el flujo de vinculación, pero antes del consentimiento del usuario (es decir, la autorización) se consideran proximales y, por lo tanto, remotas.
  • Los errores que ocurren después de establecer el consentimiento del usuario se consideran locales, incluso si la vinculación finalmente falla.

Los vectores de ataque físico se consideran locales. Entre ellas, se incluyen los errores que solo pueden aprovechar 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. Debido a que es común que los dispositivos se desbloqueen enchufado a un USB, los ataques que requieren una conexión USB tienen la misma gravedad, independientemente del si es necesario desbloquear el dispositivo o no.

Seguridad de red

Android supone que todas las redes son hostiles y podrían inyectar ataques o espiar tráfico. Por otro lado, 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 asegurar los enlaces restantes en la cadena entre el dispositivo y los servidores con los que se está comunicando.

Por el contrario, HTTPS suele proteger toda la comunicación de extremo a extremo, en su origen, para luego desencriptarlo y verificarlo cuando llegue a su destino final. Debido a esto, las vulnerabilidades que comprometen la seguridad de la red de la capa de vínculos tienen una calificación menor graves que las vulnerabilidades de HTTPS/TLS: la encriptación de Wi-Fi por sí sola no es suficiente para la mayoría de la comunicación 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: Mejoras en la pantalla de bloqueo y la autenticación en Android 11). Estas calificaciones de gravedad distinguen entre dos clases de ataques y están destinadas a reflejan 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 por parte del propietario. Si, por ejemplo, un atacante puede colocar un trozo de goma de mascar en un sensor de huellas dactilares y otorga acceso al dispositivo según el residuo que deja. en el sensor. Se trata de un ataque simple que se podría realizar en cualquier dispositivo susceptible. Integra no requiere ningún conocimiento del propietario del dispositivo. Ya que es generalizable y puede afectar a una mayor cantidad de usuarios, este ataque recibe la calificación de gravedad completa (por ejemplo, Alto, para una omisión de la pantalla bloqueada).

La otra clase de ataques generalmente involucra un instrumento de ataque de presentación (falsificación) basado en 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 una persona en redes sociales es suficiente para engañar a la autenticación biométrica una derivación biométrica recibe la calificación de gravedad completa). Pero si un atacante necesitaría para adquirir datos biométricos directamente del propietario del dispositivo (por ejemplo, un escaneo infrarrojo de cara), es una barrera lo suficientemente significativa como para limitar el número de personas afectadas por el ataque, así que hay un modificador -1.

SYSTEM_ALERT_WINDOW y Tapjacking

Para obtener información acerca de nuestras políticas sobre SYSTEM_ALERT_WINDOW y el tapjacking, consulta “vulnerabilidad de tapjacking/overlay SYSTEM_ALERT_WINDOW en una pantalla que no es fundamental para la seguridad” del curso de la BugHunter University Errores sin impacto de seguridad .

Seguridad multiusuario en el SO Android Automotive

El SO Android Automotive adopta un modelo de seguridad multiusuario diferente de los otros factores de forma. Cada usuario de Android está diseñado para que lo utilice un equipo persona física. Por ejemplo, un usuario invitado temporal puede asignarse a un amigo que pide prestado el vehículo por su propietario. Para adaptarse a casos de uso como este, los usuarios tienen acceso a los componentes necesarios para usar el vehículo, como Wi-Fi y red móvil configuración.

Componente afectado

El equipo de desarrollo responsable de corregir el error depende del componente en el que se encuentra. Podría ser un componente central de la plataforma de Android, un controlador de kernel proporcionado por una versión fabricante del equipo (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. Errores de gravedad baja, errores en ciertos componentes, o errores que ya son conocidos públicamente se pueden corregir directamente en la rama principal de AOSP disponible públicamente; De lo contrario, se corregirán en nuestros repositorios internos antes de empezar.

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

Notifica a los socios

Cuando se corrija una vulnerabilidad de seguridad en el AOSP en un boletín de seguridad de Android, notificaremos Los socios de Android que se encargan de los detalles de los problemas y proporcionan parches. Lista de versiones compatibles con portabilidad a versiones anteriores cambian con cada versión nueva de Android. Comunícate con el fabricante del dispositivo para obtener la lista de compatibles.

Cómo lanzar código para AOSP

Si el error de seguridad está en un componente del AOSP, la solución se envía al AOSP una vez que se realiza la actualización inalámbrica lanzar a los usuarios. Las correcciones de problemas de gravedad baja se pueden enviar directamente al sitio principal del AOSP. antes de que una solución esté disponible para los dispositivos a través de OTA.

Recibiendo actualizaciones de Android

Las actualizaciones del sistema Android generalmente se entregan a los dispositivos a través de paquetes de actualización OTA. Es posible que estas actualizaciones provengan del OEM que produjo el dispositivo o el operador que proporciona servicio al dispositivo. Las actualizaciones de los dispositivos Google Pixel provienen del equipo de Google Pixel después de la fecha de lanzamiento. a través de 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 transferirse a los dispositivos.

Actualizando servicios de Google

Además de proporcionar parches para errores de seguridad, el equipo de seguridad de Android revisa las errores para determinar si hay otras formas de proteger a los usuarios. Por ejemplo, Google Play escanea todos apps y quita cualquier app que intente aprovecharse de un error de seguridad. Para 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 acerca de aplicaciones 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 existe en todos los sitios de código abierto y para desarrolladores de Android. Bueno lugares para comenzar:

Informes

A veces, el equipo de seguridad de Android publica informes. Consulta Informes de seguridad para obtener más información.