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. Las fuentes de errores externos incluyen problemas informados a través de la plantilla de problemas de seguridad de Android , investigaciones académicas publicadas y prepublicadas, mantenedores de proyectos de código abierto, notificaciones de nuestros socios fabricantes de dispositivos y problemas divulgados públicamente publicados en blogs o redes sociales.
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 informe de vulnerabilidades 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.
Triaging 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 proceso
Esta tabla cubre las definiciones de los tipos de procesos. El tipo de proceso se puede definir por el tipo de aplicación o proceso o el área en la que se ejecuta. Esta tabla está ordenada de menor a mayor privilegio.
Tipo de proceso | Definición de tipo |
---|---|
Proceso restringido | Un proceso que se ejecuta en un dominio SELinux muy limitado. O Un proceso que es significativamente más limitado que una aplicación normal. |
Proceso sin privilegios | Una aplicación o proceso que se ejecuta en un dominio SELinux con el atributo untrusted_app_all , o está restringido de manera equivalente. |
Proceso privilegiado | Una aplicación o proceso con capacidades que estarían prohibidas por el dominio untrusted_app SELinux.O Una aplicación o proceso con privilegios importantes que una aplicación de terceros no puede obtener. O Un componente de hardware integrado en el dispositivo que no forma parte de la base informática confiable (TCB). |
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 del dispositivo), tiene la capacidad de cargar scripts en un componente del kernel ( por ejemplo, eBPF), el procesador de banda base, o es uno de los pocos servicios de usuario que se considera equivalente al kernel: apexd , bpfloader , init , ueventd y vold . |
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). |
Elemento seguro (SE) | Un componente 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 los elementos seguros . |
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 |
|
Alto |
|
Moderar |
|
Bajo |
|
Impacto de seguridad insignificante (NSI) |
|
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 proceso 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 teléfono 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 teléfono está encendido y ha sido desbloqueado previamente | -2 gravedad |
Un ataque local que requiere que el cargador de arranque esté desbloqueado | 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é actualmente habilitado en el dispositivo (y no es un error en el modo de desarrollador). | No más alto que bajo |
Si ningún dominio 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, el equipo de seguridad de Android también considera 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 de destino, por ejemplo, un error que requiere el envío de paquetes Wi-Fi o Bluetooth mal formados. El equipo de seguridad de Android considera que los ataques basados en NFC son proximales 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 . 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 requiera conectar 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 wifi
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 de Wi-Fi 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 comunica. .
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 Wi-Fi 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 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 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 un desvío de la pantalla de bloqueo).
La otra clase de ataques generalmente involucra un instrumento de ataque de presentación (spoof) 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 -1 .
Componente afectado
El equipo de desarrollo responsable de corregir el error depende del componente en el que se encuentre. 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 principal 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 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 corrige 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 correcció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 se pueden cargar en los dispositivos.
Actualizar 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 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 todos los sitios de código abierto y desarrolladores de Android. Buenos lugares para comenzar:
- https://source.android.com/security/index
- https://developer.android.com/training/articles/security-tips
Informes
A veces, el equipo de seguridad de Android publica informes o documentos técnicos. Consulte los informes de seguridad para obtener más detalles.