Mises à jour et ressources de sécurité

L'équipe de sécurité Android est chargée de gérer les vulnérabilités de sécurité découvertes dans la plate-forme Android et dans de nombreuses applications Android principales fournies avec les appareils Android.

L'équipe de sécurité Android détecte les failles de sécurité grâce à des recherches internes et répond également aux bugs signalés par des tiers. Les sources de bogues externes incluent les problèmes signalés via le formulaire de vulnérabilité , les recherches universitaires publiées et prépubliées, les responsables de projets open source en amont, les notifications de nos partenaires fabricants d'appareils et les problèmes divulgués publiquement publiés sur les blogs ou les réseaux sociaux.

Signaler des problèmes de sécurité

Tout développeur, utilisateur Android ou chercheur en sécurité peut informer l'équipe de sécurité Android des problèmes de sécurité potentiels via le formulaire de vulnérabilité .

Les bogues marqués comme problèmes de sécurité ne sont pas visibles de l’extérieur, mais ils peuvent éventuellement être rendus visibles une fois le problème évalué ou résolu. Si vous envisagez de soumettre un correctif ou un test CTS (Compatibility Test Suite) pour résoudre un problème de sécurité, veuillez le joindre au rapport de bogue et attendre une réponse avant de télécharger le code sur AOSP.

Trier les bogues

La première tâche dans la gestion d’une vulnérabilité de sécurité consiste à identifier la gravité du bug et quel composant d’Android est affecté. La gravité détermine la manière dont le problème est priorisé et le composant détermine qui corrige le bogue, qui est averti et comment le correctif est déployé auprès des utilisateurs.

Types de contexte

Ce tableau couvre les définitions des contextes de sécurité matérielle et logicielle. Le contexte peut être défini par la sensibilité des données qu'il traite généralement ou par la zone dans laquelle il s'exécute. Tous les contextes de sécurité ne sont pas applicables à tous les systèmes. Ce tableau est classé du moins au plus privilégié.

Type de contexte Définition du type
Contexte contraint Un environnement d'exécution restreint où seules les autorisations les plus minimes sont fournies.

Par exemple, des applications approuvées traitant des données non fiables dans un environnement sandbox.
Contexte peu privilégié Un environnement d'exécution typique attendu par du code non privilégié.

Par exemple, une application Android qui s'exécute dans un domaine SELinux avec l'attribut untrusted_app_all .
Contexte privilégié Un environnement d'exécution privilégié qui peut avoir accès à des autorisations élevées, gérer les informations personnelles de plusieurs utilisateurs et/ou maintenir l'intégrité du système.

Par exemple, une application Android avec des fonctionnalités qui seraient interdites par le domaine SELinux untrusted_app ou avec un accès à des autorisations privileged|signature .
Noyau du système d'exploitation Fonctionnalité qui :
  • fait partie du noyau
  • s'exécute dans le même contexte CPU que le noyau (par exemple, les pilotes de périphériques)
  • a un accès direct à la mémoire du noyau (par exemple, les composants matériels du périphérique)
  • a la capacité de charger des scripts dans un composant du noyau (par exemple, eBPF)
  • est l'un des rares services utilisateur considérés comme équivalents au noyau (tels que apexd , bpfloader , init , ueventd et vold ).
Base matérielle de confiance (THB) Composants matériels discrets, généralement sur le SoC, qui fournissent des fonctionnalités essentielles aux principaux cas d'utilisation de l'appareil (tels que les bandes de base cellulaires, les DSP, les GPU et les processeurs ML).
Chaîne de chargeur de démarrage Un composant qui configure l'appareil au démarrage, puis passe le contrôle au système d'exploitation Android.
Environnement d'exécution fiable (TEE) Un composant conçu pour être protégé même contre un noyau de système d'exploitation hostile (par exemple, TrustZone et des hyperviseurs, tels que pKVM, qui protègent les machines virtuelles du noyau du système d'exploitation).
Enclave sécurisée / Élément sécurisé (SE) Un composant matériel facultatif conçu pour être protégé de tous les autres composants de l'appareil et des attaques physiques, comme défini dans Introduction aux éléments sécurisés .

Cela inclut la puce Titan-M présente dans certains appareils Android.

Gravité

La gravité d'un bug reflète généralement le préjudice potentiel qui pourrait survenir si un bug était exploité avec succès. Utilisez les critères suivants pour déterminer la gravité.

Notation Conséquence d'une exploitation réussie
Critique
  • Exécution de code arbitraire dans le TEE ou le SE
  • Contournement des mécanismes logiciels destinés à empêcher tout dysfonctionnement de composants logiciels ou matériels liés à la sécurité (par exemple, protections thermiques)
  • Accès à distance aux informations d'identification sensibles utilisées pour l'authentification du service à distance (par exemple, mots de passe de compte ou jetons de porteur)
  • Exécution de code arbitraire à distance dans le contexte de la bande de base cellulaire sans interaction de l'utilisateur (par exemple, exploitation d'un bug dans le service radio cellulaire)
  • Exécution de code arbitraire à distance dans un contexte privilégié, la chaîne du bootloader, le THB ou le noyau du système d'exploitation
  • Contournement à distance des exigences d'interaction de l'utilisateur lors de l'installation du package ou comportement équivalent
  • Contournement à distance des exigences d'interaction utilisateur pour les paramètres principaux du développeur, de la sécurité ou de la confidentialité
  • Déni de service persistant à distance (permanent, nécessitant un reflasher de l'intégralité du système d'exploitation ou une réinitialisation d'usine)
  • Contournement du démarrage sécurisé à distance
  • Accès non autorisé aux données sécurisées par le SE, y compris l'accès activé par des clés faibles dans le SE.
Haut
  • Un contournement complet d'une fonctionnalité de sécurité principale (par exemple, SELinux, FBE ou seccomp )
  • Un contournement général pour une défense en profondeur ou exploiter la technologie d'atténuation dans la chaîne du chargeur de démarrage, TEE ou SE
  • Un contournement général des protections du système d'exploitation qui révèlent le contenu de la mémoire ou des fichiers au-delà des limites de l'application, de l'utilisateur ou du profil.
  • Attaques contre un SE entraînant une rétrogradation vers une implémentation moins sécurisée
  • Pivoter d'un micrologiciel nu compromis accessible à distance (par exemple, bande de base, CP/processeur de communication) vers le noyau du processeur d'application (AP) ou des mécanismes de contournement conçus pour isoler le micrologiciel nu du noyau AP
  • Contournement de la protection de l'appareil/protection contre la réinitialisation d'usine/restrictions de l'opérateur
  • Contournement des exigences d'interaction utilisateur sécurisées par le TEE
  • Vulnérabilité cryptographique qui permet des attaques contre les protocoles de bout en bout, y compris des attaques contre la sécurité de la couche de transport (TLS) et Bluetooth (BT).
  • Accès local aux informations d'identification sensibles utilisées pour l'authentification du service à distance (par exemple, mots de passe de compte ou jetons de porteur)
  • Exécution locale de code arbitraire dans un contexte privilégié, la chaîne du bootloader, le THB ou le noyau du système d'exploitation
  • Contournement du démarrage sécurisé local
  • Contournement de l'écran de verrouillage
  • Contournement local des exigences d'interaction utilisateur pour les paramètres principaux du développeur, de la sécurité ou de la confidentialité
  • Contournement local des exigences d'interaction de l'utilisateur lors de l'installation du package ou comportement équivalent
  • Déni de service local persistant (permanent, nécessitant un reflasher de l'intégralité du système d'exploitation ou une réinitialisation d'usine)
  • Accès à distance aux données protégées (c'est-à-dire aux données limitées à un contexte privilégié)
  • Exécution de code arbitraire à distance dans un contexte non privilégié
  • Prévention à distance de l'accès au service cellulaire ou Wi-Fi sans interaction de l'utilisateur (par exemple, blocage du service radio cellulaire avec un paquet mal formé)
  • Contournement à distance des exigences d'interaction de l'utilisateur (accès aux fonctionnalités ou aux données qui devraient nécessiter l'initiation ou l'autorisation de l'utilisateur)
  • Prévention ciblée de l’accès aux services d’urgence
  • Transmission d'informations sensibles via un protocole réseau non sécurisé (par exemple, HTTP et Bluetooth non crypté) lorsque le demandeur s'attend à une transmission sécurisée. Notez que cela ne s'applique pas au cryptage Wi-Fi (tel que WEP)
  • Accès non autorisé aux données sécurisées par le TEE, y compris l'accès activé par des clés faibles dans le TEE
Modéré
  • Un contournement général pour une défense en profondeur ou exploiter une technologie d'atténuation dans un contexte privilégié, le THB, ou le noyau de l'OS
  • Un contournement général des protections du système d'exploitation qui révèlent l'état du processus ou les métadonnées au-delà des limites de l'application, de l'utilisateur ou du profil.
  • Contourner le cryptage ou l'authentification Wi-Fi
  • Vulnérabilité cryptographique dans les primitives cryptographiques standard qui permet la fuite de texte en clair (pas les primitives utilisées dans TLS)
  • Accès local aux données protégées (c'est-à-dire aux données limitées à un contexte privilégié)
  • Exécution locale de code arbitraire dans un contexte non privilégié
  • Contournement local des exigences d'interaction de l'utilisateur (accès à des fonctionnalités ou à des données qui nécessiteraient normalement l'initiation ou l'autorisation de l'utilisateur)
  • Accès à distance aux données non protégées (c'est-à-dire aux données normalement accessibles à toute application installée localement)
  • Exécution de code arbitraire à distance dans un contexte contraint
  • Déni de service temporaire d’un appareil à distance (blocage ou redémarrage à distance)
Faible
  • Un contournement général pour une défense en profondeur au niveau de l'utilisateur ou exploiter une technologie d'atténuation dans un contexte non privilégié
  • Contournement d'une autorisation de niveau de protection normal
  • Vulnérabilité cryptographique en usage non standard
  • Contournement général des fonctionnalités de personnalisation sur l'appareil telles que Voice Match ou Face Match
  • Documentation incorrecte pouvant conduire à une faille de sécurité
  • Exécution de code arbitraire local dans un contexte contraint
  • Texte défini par le système qui inclut une description trompeuse qui crée de fausses attentes en matière de sécurité
Impact négligeable sur la sécurité (NSI​)
  • Une vulnérabilité dont l'impact a été atténué par un ou plusieurs modificateurs de notation ou des modifications d'architecture spécifiques à la version, de sorte que la gravité effective est inférieure à Faible, bien que le problème de code sous-jacent puisse persister.
  • Toute vulnérabilité nécessitant un système de fichiers mal formé, si ce système de fichiers est toujours adopté/chiffré avant utilisation.
  • Déni de service temporaire local , par exemple lorsque la condition peut être résolue en redémarrant l'appareil ou en désinstallant l'application déclenchante.

Modificateurs de notation

Même si la gravité des failles de sécurité est souvent facile à identifier, les notes peuvent changer en fonction des circonstances.

Raison Effet
Nécessite une exécution dans un contexte privilégié pour exécuter l'attaque (non applicable à TEE, SE et aux hyperviseurs tels que pKVM) -1 Gravité
Les détails spécifiques à la vulnérabilité limitent l'impact du problème -1 Gravité
Contournement de l'authentification biométrique qui nécessite des informations biométriques directement du propriétaire de l'appareil -1 Gravité
Les configurations du compilateur ou de la plateforme atténuent une vulnérabilité dans le code source Gravité modérée si la vulnérabilité sous-jacente est modérée ou supérieure
Nécessite un accès physique aux composants internes de l'appareil et reste possible si l'appareil est éteint ou n'a pas été déverrouillé depuis sa mise sous tension. -1 Gravité
Nécessite un accès physique aux composants internes de l'appareil lorsque celui-ci est allumé et a déjà été déverrouillé -2 Gravité
Une attaque locale qui nécessite le déverrouillage de la chaîne du bootloader Pas supérieur à Faible
Une attaque locale qui nécessite que le mode développeur ou tout autre paramètre persistant du mode développeur soit actuellement activé sur l'appareil (et ne constitue pas un bug dans le mode développeur lui-même). Pas supérieur à Faible
Si aucun domaine SELinux ne peut effectuer l'opération dans le cadre de la SEPolicy fournie par Google Impact de sécurité négligeable

Local versus proximal versus distant

Un vecteur d'attaque à distance indique que le bug peut être exploité sans installer d'application ou sans accès physique à un appareil. Cela inclut les bugs qui peuvent être déclenchés lors de la navigation sur une page Web, de la lecture d'un e-mail, de la réception d'un message SMS ou de la connexion à un réseau hostile. Aux fins de nos évaluations de gravité, nous considérons également les vecteurs d’attaque « proximaux » comme éloignés. Il s'agit notamment de bugs qui ne peuvent être exploités que par un attaquant physiquement proche de l'appareil cible, par exemple un bug qui nécessite l'envoi de paquets Wi-Fi ou Bluetooth mal formés. Nous considérons les attaques ultra-large bande (UWB) et basées sur NFC comme proximales et donc distantes.

Les attaques locales nécessitent que la victime exécute une application, soit en installant et en exécutant une application, soit en consentant à exécuter une application instantanée . Les appareils compagnons couplés seront considérés comme locaux. Aux fins des évaluations de gravité, l’équipe de sécurité Android considère également les vecteurs d’attaque physique comme locaux. Il s'agit notamment de bugs qui ne peuvent être exploités que par un attaquant ayant un accès physique à l'appareil, par exemple un bug dans un écran de verrouillage ou celui qui nécessite de brancher un câble USB.

Sécurité Internet

Android suppose que tous les réseaux sont hostiles et pourraient lancer des attaques ou espionner le trafic. Bien que la sécurité au niveau de la couche de liaison (par exemple, le cryptage Wi-Fi) sécurise la communication entre un appareil et le point d'accès auquel il est connecté, elle ne fait rien pour sécuriser les maillons restants de la chaîne entre l'appareil et les serveurs avec lesquels il communique.

En revanche, HTTPS protège généralement l'intégralité de la communication de bout en bout, en chiffrant les données à leur source, puis en les déchiffrant et en les vérifiant uniquement une fois qu'elles ont atteint leur destination finale. Pour cette raison, les vulnérabilités qui compromettent la sécurité du réseau au niveau de la couche liaison sont jugées moins graves que les vulnérabilités HTTPS/TLS : le cryptage Wi-Fi à lui seul est insuffisant pour la plupart des communications sur Internet.

Authentification biométrique

L'authentification biométrique est un domaine difficile, et même les meilleurs systèmes peuvent être trompés par une quasi-correspondance (voir le blog des développeurs Android : écran de verrouillage et améliorations de l'authentification dans Android 11 ). Ces niveaux de gravité distinguent deux classes d'attaques et visent à refléter le risque réel pour l'utilisateur final.

La première classe d'attaques permet de contourner l'authentification biométrique de manière généralisable, sans données biométriques de haute qualité de la part du propriétaire. Si, par exemple, un attaquant peut placer un morceau de chewing-gum sur un capteur d'empreintes digitales et que celui-ci autorise l'accès à l'appareil en fonction des résidus laissés sur le capteur, il s'agit d'une attaque simple qui pourrait être menée sur n'importe quel appareil sensible. Cela ne nécessite aucune connaissance du propriétaire de l’appareil. Étant donné qu'elle est généralisable et qu'elle peut potentiellement affecter un plus grand nombre d'utilisateurs, cette attaque reçoit l'indice de gravité complet (par exemple, Élevé, pour un contournement de Lockscreen).

L'autre classe d'attaques implique généralement un instrument d'attaque de présentation (usurpation d'identité) basé sur le propriétaire de l'appareil. Parfois, ces informations biométriques sont relativement faciles à obtenir (par exemple, si la photo de profil d'une personne sur les réseaux sociaux suffit à tromper l'authentification biométrique, alors un contournement biométrique recevrait l'indice de gravité complet). Mais si un attaquant a besoin d'acquérir des données biométriques directement auprès du propriétaire de l'appareil (par exemple, un scan infrarouge de son visage), cela constitue une barrière suffisamment importante pour limiter le nombre de personnes affectées par l'attaque, il y a donc un modificateur de -1. .

SYSTEM_ALERT_WINDOW et Tapjacking

Pour plus d'informations sur nos politiques concernant SYSTEM_ALERT_WINDOW et le tapjacking, consultez la section « Vulnérabilité Tapjacking/overlay SYSTEM_ALERT_WINDOW sur un écran non critique pour la sécurité » de la page BugHunter University's Bugs sans impact sur la sécurité .

Sécurité multi-utilisateurs dans le système d'exploitation Android Automotive

Android Automotive OS adopte un modèle de sécurité multi-utilisateurs différent des autres facteurs de forme. Chaque utilisateur Android a vocation à être utilisé par une personne physique différente. Par exemple, un utilisateur invité temporaire peut être attribué à un ami qui emprunte le véhicule au propriétaire de la voiture. Pour répondre à des cas d'utilisation comme celui-ci, les utilisateurs ont accès par défaut aux composants nécessaires à l'utilisation du véhicule, tels que les paramètres du réseau Wi-Fi et cellulaire.

Composant concerné

L'équipe de développement responsable de la correction du bug dépend du composant dans lequel se trouve le bug. Il peut s'agir d'un composant central de la plate-forme Android, d'un pilote de noyau fourni par un fabricant d'équipement d'origine (OEM) ou de l'une des applications préchargées sur les appareils Pixel. .

Les bogues dans le code AOSP sont corrigés par l'équipe d'ingénierie Android. Les bogues de faible gravité, les bogues dans certains composants ou les bogues déjà connus du public peuvent être corrigés directement dans la branche principale AOSP accessible au public ; sinon, ils sont d'abord corrigés dans nos référentiels internes.

Le composant est également un facteur dans la manière dont les utilisateurs obtiennent les mises à jour. Un bogue dans le framework ou le noyau nécessite une mise à jour du micrologiciel OTA (over-the-air) que chaque OEM doit pousser. Un bug dans une application ou une bibliothèque publiée sur Google Play (par exemple, Gmail, les services Google Play ou WebView) peut être envoyé aux utilisateurs d'Android sous forme de mise à jour depuis Google Play.

Notifier les partenaires

Lorsqu'une vulnérabilité de sécurité dans AOSP est corrigée dans un bulletin de sécurité Android, nous informons les partenaires Android des détails du problème et fournissons des correctifs. La liste des versions prises en charge par le backport change à chaque nouvelle version d'Android. Contactez le fabricant de votre appareil pour obtenir la liste des appareils pris en charge.

Publication du code sur AOSP

Si le bogue de sécurité se trouve dans un composant AOSP, le correctif est transmis à AOSP après la publication de l'OTA aux utilisateurs. Les correctifs pour les problèmes de faible gravité peuvent être soumis directement à la branche principale de l'AOSP avant qu'un correctif ne soit disponible pour les appareils via une OTA.

Recevoir des mises à jour Android

Les mises à jour du système Android sont généralement fournies aux appareils via des packages de mise à jour OTA. Ces mises à jour peuvent provenir du fabricant OEM qui a produit l'appareil ou de l'opérateur qui fournit le service à l'appareil. Les mises à jour des appareils Google Pixel proviennent de l'équipe Google Pixel après avoir été soumises à une procédure de test d'acceptation technique (TA) par l'opérateur. Google publie également des images d'usine Pixel qui peuvent être chargées sur les appareils.

Mise à jour des services Google

En plus de fournir des correctifs pour les bogues de sécurité, l'équipe de sécurité Android examine les bogues de sécurité pour déterminer s'il existe d'autres moyens de protéger les utilisateurs. Par exemple, Google Play analyse toutes les applications et supprime toute application tentant d'exploiter un bug de sécurité. Pour les applications installées en dehors de Google Play, les appareils dotés des services Google Play peuvent également utiliser la fonctionnalité Vérifier les applications pour avertir les utilisateurs des applications potentiellement dangereuses.

Autres ressources

Informations destinées aux développeurs d'applications Android : https://developer.android.com

Des informations de sécurité existent sur les sites Android Open Source et Developer. Bons points de départ :

Rapports

Parfois, l'équipe de sécurité Android publie des rapports ou des livres blancs. Voir Rapports de sécurité pour plus de détails.