Mises à jour et ressources de sécurité

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

L'équipe de sécurité Android identifie les failles de sécurité grâce à des recherches internes et répond également aux bugs signalés par des tiers. Les sources de bugs externes incluent les problèmes signalés via le formulaire de signalement des failles, 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 sur des 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 signalement des failles.

Les bugs marqués comme problèmes de sécurité ne sont pas visibles en externe, mais ils peuvent le devenir une fois le problème évalué ou résolu. Si vous prévoyez d'envoyer un correctif ou un test Compatibility Test Suite (CTS) pour résoudre un problème de sécurité, veuillez le joindre au rapport de bug et attendre une réponse avant d'importer le code dans AOSP.

Trier les bugs

La première tâche à effectuer pour gérer une faille de sécurité consiste à identifier la gravité du bug et le composant d'Android concerné. La gravité détermine la priorité du problème, et le composant détermine qui corrige le bug, qui est averti et comment le correctif est déployé auprès des utilisateurs.

Types de contexte

Ce tableau présente les définitions des contextes de sécurité matériels et logiciels. 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 s'appliquent pas à tous les systèmes. Ce tableau est classé du moins au plus privilégié.

Type de contexte Définition du type
Contexte contraint Environnement d'exécution restreint dans lequel seules les autorisations les plus minimales sont fournies.

Par exemple, les applications de confiance traitant des données non fiables dans un environnement de bac à sable.
Contexte non privilégié Environnement d'exécution typique attendu par le 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é Environnement d'exécution privilégié pouvant avoir accès à des autorisations élevées, gérer plusieurs informations permettant d'identifier personnellement l'utilisateur 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 accès aux autorisations privileged|signature.
Noyau de l'OS Fonctionnalités :
  • fait partie du noyau
  • s'exécute dans le même contexte de processeur 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 de l'appareil) ;
  • est capable de charger des scripts dans un composant du noyau (par exemple, eBPF)
  • fait partie des rares services utilisateur considérés comme équivalents au noyau (par exemple, apexd, bpfloader, init, ueventd et vold).
Trusted Hardware Base (THB) Composants matériels distincts, 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 du bootloader Composant qui configure l'appareil au démarrage, puis transmet le contrôle à l'OS Android.
Environnement d'exécution sécurisé (TEE) Composant conçu pour être protégé même contre un noyau d'OS hostile (par exemple, TrustZone et les hyperviseurs, tels que pKVM, qui protègent les machines virtuelles du noyau d'OS).
Secure Enclave / Composant sécurisé (SE) Composant matériel facultatif conçu pour être protégé de tous les autres composants de l'appareil et des attaques physiques, tel que défini dans Introduction to Secure Elements (Présentation des éléments sécurisés).

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

Niveau

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 le niveau de gravité.

Avis Conséquence d'une exploitation réussie
Critique
  • Exécution de code arbitraire dans le TEE ou l'élément sécurisé
  • Contournement des mécanismes logiciels conçus pour empêcher le dysfonctionnement des composants logiciels ou matériels liés à la sécurité (par exemple, les protections thermiques)
  • Accès à distance aux identifiants sensibles utilisés pour l'authentification des services à distance (par exemple, les mots de passe de compte ou les jetons de support)
  • Exécution de code arbitraire à distance dans le contexte de la bande de base cellulaire sans interaction de l'utilisateur (par exemple, en exploitant un bug dans le service de radio cellulaire)
  • Exécution de code arbitraire à distance dans un contexte privilégié, la chaîne du bootloader, THB ou le noyau de l'OS
  • Contournement à distance des exigences d'interaction utilisateur lors de l'installation de packages ou d'un comportement équivalent
  • Contournement à distance des exigences d'interaction utilisateur pour les paramètres principaux de développeur, de sécurité ou de confidentialité
  • Déni de service persistant à distance (permanent, nécessitant le reflashage de l'intégralité du système d'exploitation ou le rétablissement de la configuration d'usine)
  • Contournement du démarrage sécurisé à distance
  • Accès non autorisé aux données sécurisées par l'élément sécurisé, y compris l'accès activé par des clés faibles dans l'élément sécurisé.
Haute
  • Contournement complet d'une fonctionnalité de sécurité essentielle (par exemple, SELinux, FBE ou seccomp)
  • Contournement général d'une technologie de défense en profondeur ou d'atténuation des exploits dans la chaîne du bootloader, TEE ou SE
  • Contournement général des protections du système d'exploitation qui révèle le contenu de la mémoire ou des fichiers au-delà des limites des applications, des utilisateurs ou des profils
  • Attaques contre un élément sécurisé entraînant un retour à une implémentation moins sécurisée
  • Pivotez à partir du micrologiciel Bare Metal compromis et accessible à distance (par exemple, bande de base, processeur de communication (CP)) vers le noyau du processeur d'application (AP) ou contournez les mécanismes conçus pour isoler le micrologiciel Bare Metal du noyau AP.
  • Contournement de la protection de l'appareil, de la protection après rétablissement de la configuration d'usine (dans Android 15 et versions ultérieures) ou des restrictions de l'opérateur
  • Contournement des exigences d'interaction utilisateur sécurisées par le TEE
  • Vulnérabilité cryptographique permettant des attaques contre les protocoles de bout en bout, y compris les attaques contre TLS (Transport Layer Security) et Bluetooth (BT).
  • Accès local aux identifiants sensibles utilisés pour l'authentification des services à distance (par exemple, mots de passe de compte ou jetons de support)
  • Exécution de code arbitraire local dans un contexte privilégié, la chaîne du bootloader, THB ou le noyau de l'OS
  • 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 de développement, de sécurité ou de confidentialité
  • Contournement local des exigences d'interaction utilisateur lors de l'installation de packages ou d'un comportement équivalent
  • Déni de service persistant local (permanent, nécessitant le reflashage de l'intégralité du système d'exploitation ou le rétablissement de la configuration d'usine)
  • Accès à distance aux données protégées (c'est-à-dire les données limitées à un contexte privilégié)
  • Exécution de code arbitraire à distance dans un contexte non privilégié
  • Déni de service à distance pour le service de réseau mobile ou Wi-Fi qui persiste jusqu'à l'intervention de l'utilisateur, déclenché sans interaction de l'utilisateur (par exemple, un plantage du service de radio mobile avec un paquet mal formé qui n'est pas récupéré automatiquement et nécessite un redémarrage manuel ou un redémarrage de l'appareil).
  • Contournement à distance des exigences d'interaction utilisateur (accès à des fonctionnalités ou à des données qui devraient nécessiter une action ou une autorisation de l'utilisateur)
  • Empêcher l'accès aux services d'urgence de manière ciblée
  • Transmettre des informations sensibles via un protocole réseau non sécurisé (par exemple, HTTP et Bluetooth non chiffré) lorsque le demandeur s'attend à une transmission sécurisée. Notez que cela ne s'applique pas au chiffrement Wi-Fi (par exemple, WEP).
  • Accès non autorisé aux données sécurisées par l'environnement d'exécution sécurisé, y compris l'accès autorisé par des clés faibles dans l'environnement d'exécution sécurisé
Modérée
  • Contournement général d'une technologie de défense en profondeur ou d'atténuation des failles dans un contexte privilégié, THB ou le noyau de l'OS
  • Contournement général des protections du système d'exploitation qui révèle l'état ou les métadonnées des processus au-delà des limites des applications, des utilisateurs ou des profils
  • Contourner le chiffrement ou l'authentification Wi-Fi
  • Vulnérabilité cryptographique dans les primitives cryptographiques standards qui permet la fuite de texte brut (et non 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 de code arbitraire local dans un contexte non privilégié
  • Contournement local des exigences d'interaction utilisateur (accès à des fonctionnalités ou à des données qui nécessitent normalement une initiation ou une autorisation de l'utilisateur)
  • Accès à distance aux données non protégées (c'est-à-dire les données normalement accessibles à toute application installée localement)
  • Exécution de code arbitraire à distance dans un contexte contraint
  • Déni de service temporaire à distance (blocage ou redémarrage à distance)
Faible
  • Contournement général d'une technologie de défense en profondeur ou d'atténuation des exploits au niveau de l'utilisateur dans un contexte non privilégié
  • Contournement d'une autorisation de niveau de protection normal
  • Faille cryptographique dans une utilisation non standard
  • Contournement général des fonctionnalités de personnalisation sur l'appareil, comme Voice Match ou Face Match
  • Documentation incorrecte pouvant entraîner 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 créant une fausse attente de sécurité
Impact négligeable sur la sécurité (NSI)
  • Une faille dont l'impact a été atténué par un ou plusieurs modificateurs de classification ou par des modifications de l'architecture spécifiques à une version, de sorte que la gravité effective est inférieure à "Faible", même si le problème de code sous-jacent peut subsister
  • Toute faille de sécurité nécessitant un système de fichiers mal formé, si ce système de fichiers est toujours adopté/chiffré avant utilisation.
  • Refus 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 gravité

Bien qu'il soit souvent facile d'identifier la gravité des failles de sécurité, les niveaux de gravité peuvent changer en fonction des circonstances.

Motif Effet
Nécessite une exécution dans un contexte privilégié pour exécuter l'attaque (ne s'applique pas à TEE, SE et aux hyperviseurs tels que pKVM) Gravité -1
Les détails spécifiques aux failles limitent l'impact du problème Gravité -1
Contournement de l'authentification biométrique nécessitant des informations biométriques directement du propriétaire de l'appareil Gravité -1
Les configurations du compilateur ou de la plate-forme atténuent une faille dans le code source. Gravité modérée si la faille sous-jacente est modérée ou plus
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 son allumage Gravité -1
Nécessite un accès physique aux composants internes de l'appareil lorsqu'il est allumé et a déjà été déverrouillé Gravité -2
Une attaque locale qui nécessite le déverrouillage de la chaîne du bootloader Pas plus élevé que "Faible"
Une attaque locale qui nécessite que le mode Développeur ou tout paramètre persistant du mode Développeur soient actuellement activés sur l'appareil (et qui n'est pas un bug du mode Développeur lui-même). Pas plus élevé que "Faible"
Si aucun domaine SELinux ne peut effectuer l'opération en vertu de la SEPolicy fournie par Google Impact négligeable sur la sécurité

Local, proximal ou distant

Un vecteur d'attaque à distance indique que le bug peut être exploité sans installer d'application ni avoir un accès physique à un appareil. Cela inclut les bugs qui peuvent être déclenchés en accédant à une page Web, en lisant un e-mail, en recevant un message SMS ou en se connectant à un réseau hostile.

Les vecteurs d'attaque proximaux sont considérés comme distants. Il s'agit, par exemple, de bugs qui ne peuvent être exploités que par un pirate informatique 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 basées sur la bande ultralarge (UWB) et la technologie NFC comme proximales et donc distantes.

Pour les attaques locales, l'attaquant doit avoir eu accès à la victime au préalable. Dans un exemple hypothétique où seul le logiciel est concerné, cela pourrait se faire par le biais d'une application malveillante installée par la victime ou d'une appli instantanée qu'elle a accepté d'exécuter.

Les appareils associés (tels que les appareils Bluetooth) sont considérés comme locaux. Nous faisons la distinction entre un appareil associé et un appareil participant à un flux d'association.

  • Les bugs qui nuisent à la capacité de l'utilisateur à identifier l'autre appareil avec lequel l'association est en cours (c'est-à-dire l'authentification) sont considérés comme proximaux et donc distaux.
  • Les bugs qui se produisent pendant le processus d'association, mais avant que le consentement (c'est-à-dire l'autorisation) de l'utilisateur n'ait été établi, sont considérés comme proximaux et donc distaux.
  • Les bugs qui se produisent après l'établissement du consentement de l'utilisateur sont considérés comme locaux, même si l'association échoue finalement.

Les vecteurs d'attaque physique sont considérés comme locaux. Il s'agit, par exemple, de bugs qui ne peuvent être exploités que par un pirate informatique ayant un accès physique à l'appareil (par exemple, un bug dans un écran de verrouillage ou un bug qui nécessite de brancher un câble USB). Comme il est courant que les appareils soient déverrouillés lorsqu'ils sont branchés sur un port USB, les attaques qui nécessitent une connexion USB ont le même niveau de gravité, que l'appareil doive être déverrouillé ou non.

Sécurité réseau

Android part du principe que tous les réseaux sont hostiles et peuvent injecter des attaques ou espionner le trafic. Bien que la sécurité de la couche liaison (par exemple, le chiffrement 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 autres maillons de la chaîne entre l'appareil et les serveurs avec lesquels il communique.

En revanche, HTTPS protège généralement l'ensemble 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. C'est pourquoi les failles qui compromettent la sécurité du réseau de couche liaison sont considérées comme moins graves que celles qui affectent HTTPS/TLS : le chiffrement Wi-Fi seul ne suffit pas pour la plupart des communications sur Internet.

Authentification biométrique

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

La première catégorie d'attaques permet de contourner l'authentification biométrique de manière généralisable, sans avoir besoin de données biométriques de haute qualité du propriétaire. Par exemple, si un pirate informatique peut placer un chewing-gum sur un lecteur d'empreinte digitale et que cela lui permet d'accéder à l'appareil en fonction des résidus laissés sur le capteur, il s'agit d'une attaque simple qui pourrait être effectuée sur n'importe quel appareil vulnérable. Il ne nécessite aucune connaissance du propriétaire de l'appareil. Étant donné qu'elle est généralisable et qu'elle peut potentiellement toucher un grand nombre d'utilisateurs, cette attaque reçoit le niveau de gravité maximal (par exemple, "Élevé" pour un contournement de l'écran de verrouillage).

L'autre catégorie d'attaques implique généralement un instrument d'attaque par présentation (usurpation d'identité) basé sur le propriétaire de l'appareil. Il est parfois relativement facile d'obtenir ces informations biométriques (par exemple, si la photo de profil d'une personne sur les réseaux sociaux suffit à tromper l'authentification biométrique, le contournement biométrique recevra le niveau de gravité maximal). Cependant, si un pirate informatique devait acquérir des données biométriques directement auprès du propriétaire de l'appareil (par exemple, une analyse infrarouge de son visage), cela constituerait un obstacle suffisamment important pour limiter le nombre de personnes touchées par l'attaque. Un modificateur de -1 est donc appliqué.

SYSTEM_ALERT_WINDOW et tapjacking

Pour en savoir plus sur nos règles concernant SYSTEM_ALERT_WINDOW et le tapjacking, consultez la section Vulnérabilité SYSTEM_ALERT_WINDOW de tapjacking/superposition sur un écran non critique pour la sécurité de la page Bugs sans impact sur la sécurité de BugHunter University.

Sécurité multi-utilisateur dans Android Automotive OS

Android Automotive OS adopte un modèle de sécurité multi-utilisateur différent des autres facteurs de forme. Chaque utilisateur Android est destiné à ê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. Pour répondre à ce type de cas d'utilisation, les utilisateurs ont accès par défaut aux composants nécessaires pour utiliser le véhicule, tels que les paramètres Wi-Fi et de réseau mobile.

Composant concerné

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

Les bugs dans le code AOSP sont corrigés par l'équipe d'ingénierie Android dans nos dépôts internes.

Ce composant est également un facteur déterminant pour la façon dont les utilisateurs reçoivent les mises à jour. Un bug dans le framework ou le noyau nécessite une mise à jour du micrologiciel OTA (Over The Air) que chaque OEM doit déployer. 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 Android sous forme de mise à jour depuis Google Play.

Informer les partenaires

Lorsqu'une faille 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 compatibles avec le rétroportage change à chaque nouvelle version d'Android. Contactez le fabricant de votre appareil pour obtenir la liste des appareils compatibles.

Publier le code sur AOSP

Si le bug de sécurité se trouve dans un composant AOSP, le correctif est envoyé à AOSP une fois l'OTA publié pour les utilisateurs.

Recevoir les mises à jour Android

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

Mettre à jour les services Google

En plus de fournir des correctifs pour les bugs de sécurité, l'équipe de sécurité Android examine les bugs 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 celles qui tentent d'exploiter un bug de sécurité. Pour les applications installées en dehors de Google Play, les appareils équipés des services Google Play peuvent également utiliser la fonctionnalité Valider les applis pour avertir les utilisateurs des applications potentiellement dangereuses.

Autres ressources

Informations pour les développeurs d'applications Android : https://developer.android.com

Des informations sur la sécurité sont disponibles sur les sites Android Open Source et pour les développeurs. Bonnes places to start:

Rapports

L'équipe de sécurité Android publie parfois des rapports ou des livres blancs. Pour en savoir plus, consultez Rapports sur la sécurité.