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étectées dans la plate-forme Android et dans de nombreuses applications Android de base 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 bugs externes incluent les problèmes signalés via le formulaire de signalement de 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 des réseaux sociaux.

Signaler des problèmes de sécurité

Tout développeur, utilisateur Android ou chercheur en sécurité peut signaler à l'équipe de sécurité Android d'éventuels problèmes de sécurité à l'aide du formulaire de signalement de failles.

Les bugs 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 prévoyez d'envoyer un correctif ou un test CTS (Compatibility Test Suite) pour résoudre un problème de sécurité, veuillez l'ajouter au rapport de bug et attendre une réponse avant d'importer le code dans AOSP.

Triage des bugs

La première tâche à accomplir 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 en est informé 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é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 trié du moins au plus privilégié.

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

Par exemple, les applications approuvées qui traitent des données non approuvées 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 personnelles d'utilisateur et/ou assurer l'intégrité du système.

Par exemple, une application Android dont les fonctionnalités seraient interdites par le domaine untrusted_app SELinux ou ayant accès aux autorisations privileged|signature.
Kernel 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 d'appareils) ;
  • dispose d'un accès direct à la mémoire du noyau (par exemple, les composants matériels de l'appareil) ;
  • peut charger des scripts dans un composant de kernel (par exemple, eBPF)
  • est l'un 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 mobiles, les DSP, les GPU et les processeurs de ML).
Chaîne de 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 contre le noyau de l'OS).
Secure Enclave / composant sécurisé (SE) Composant matériel facultatif conçu pour être protégé contre tous les autres composants de l'appareil et contre les attaques physiques, comme défini dans la section Présentation des éléments sécurisés.

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

Niveau

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

Avis Conséquence d'une exploitation réussie
Critique
  • Exécution de code arbitraire dans le TEE ou le SE
  • 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 d'assistance)
  • Exécution de code arbitraire à distance dans le contexte de la bande de base mobile sans interaction de l'utilisateur (par exemple, exploitation d'un bug dans le service radio mobile)
  • Exécution de code arbitraire à distance dans un contexte privilégié, la chaîne de bootloader, le THB ou le kernel de l'OS
  • Contournement à distance des exigences d'interaction utilisateur lors de l'installation de packages ou comportement équivalent
  • Contournement à distance des exigences d'interaction utilisateur pour les paramètres de base du développeur, de sécurité ou de confidentialité
  • Déni de service persistant à distance (permanent, nécessitant de flasher l'intégralité du système d'exploitation ou de rétablir la configuration d'usine)
  • Dépassement 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.
Haute
  • Contournement complet d'une fonctionnalité de sécurité de base (par exemple, SELinux, FBE ou seccomp)
  • Un contournement général pour une technologie de défense en profondeur ou d'atténuation des failles dans la chaîne de bootloader, le TEE ou le 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 qui entraînent une rétrogradation vers une implémentation moins sécurisée
  • Passer d'un micrologiciel bare metal compromis accessible à distance (par exemple, la bande de base, le processeur de communication (CP)) au noyau du processeur d'application (AP) ou contourner les mécanismes conçus pour isoler le micrologiciel bare metal du noyau de l'AP
  • Contournement de la protection de l'appareil, de la protection après rétablissement de la configuration d'usine 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 le protocole TLS (Transport Layer Security) et le protocole Bluetooth (BT).
  • Accès local aux identifiants sensibles utilisés pour l'authentification des services à distance (par exemple, les mots de passe de compte ou les jetons d'accès)
  • Exécution de code arbitraire local dans un contexte privilégié, la chaîne de bootloader, le THB ou le kernel 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 de base du développeur, de sécurité ou de confidentialité
  • Contournement local des exigences d'interaction utilisateur lors de l'installation de packages ou comportement équivalent
  • Déni de service local persistant (permanent, nécessitant de flasher l'intégralité du système d'exploitation ou de rétablir 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é
  • Empêchement à distance de l'accès au service de réseau mobile ou Wi-Fi sans intervention de l'utilisateur (par exemple, plantage du service de radio mobile avec un paquet mal formé)
  • Contournement à distance des exigences d'interaction utilisateur (accès à des fonctionnalités ou à des données qui doivent nécessiter une action ou une 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 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 le TEE, y compris l'accès activé par des clés faibles dans le TEE
Modérée
  • Un contournement général pour une défense en profondeur ou une technologie d'atténuation des failles dans un contexte privilégié, un 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 chiffrement ou l'authentification du Wi-Fi
  • Vulnérabilité cryptographique dans les primitives cryptographiques standards qui permet de divulguer du texte brut (pas les primitives utilisées dans TLS)
  • Accès local aux données protégées (c'est-à-dire les 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 de l'utilisateur (accès à des fonctionnalités ou à des données qui nécessiteraient normalement une action ou une autorisation de l'utilisateur)
  • Accès à distance aux données non protégées (c'est-à-dire les données normalement accessibles à n'importe quelle application installée localement)
  • Exécution de code arbitraire à distance dans un contexte contraint
  • Déni de service temporaire à distance de l'appareil (blocage ou redémarrage à distance)
Faible
  • Un contournement général pour une défense en profondeur ou une technologie de mitigation des failles au niveau de l'utilisateur dans un contexte non privilégié
  • Contournement d'une autorisation de niveau de protection normal
  • Vulnérabilité cryptographique en cas d'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 qui crée une fausse attente de sécurité
Impact de sécurité négligeable (NSI)
  • Vulnérabilité dont l'impact a été atténué par un ou plusieurs modificateurs de classification ou des modifications d'architecture spécifiques à la version, de sorte que la gravité effective est inférieure à "Faible", même si le problème de code sous-jacent peut persister
  • Toute faille 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éclencheuse.

Modificateurs de tarif

Bien que la gravité des failles de sécurité soit souvent facile à identifier, les évaluations peuvent changer en fonction des circonstances.

Motif Effet
Nécessite l'exécution en tant que contexte privilégié pour exécuter l'attaque (non applicable au TEE, au SE et aux hyperviseurs tels que pKVM) -1 Gravité
Les informations spécifiques à la faille 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 plate-forme atténuent une faille dans le code source Gravité modérée si la faille sous-jacente est de gravité modérée ou supérieure
Nécessite un accès physique à l'intérieur de l'appareil et reste possible si l'appareil est éteint ou s'il n'a pas été déverrouillé depuis son allumage -1 Gravité
Nécessite un accès physique à l'intérieur de l'appareil lorsqu'il est allumé et qu'il a déjà été déverrouillé Gravité -2
Attaque locale nécessitant le déverrouillage de la chaîne de bootloader Pas plus élevé que "Faible"
Attaque locale qui nécessite que le mode développeur ou des paramètres de mode développeur persistants 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 sous le SEPolicy fourni par Google Impact négligeable sur la sécurité

Local, proximal et distant

Un vecteur d'attaque à distance indique que le bug peut être exploité sans installer d'application ni sans avoir 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 notamment de bugs qui ne peuvent être exploités que par un pirate informatique situé physiquement à proximité 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 UWB (bande ultralarge) et NFC comme des attaques proximales et donc à distance.

Les attaques locales nécessitent que l'attaquant ait un accès préalable à la victime. Dans un exemple hypothétique de logiciel uniquement, il peut s'agir d'une application malveillante installée par la victime ou d'une application instantanée qu'elle a accepté d'exécuter.

Les appareils associés (tels que les appareils associés 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 dégradent la capacité de l'utilisateur à identifier l'autre appareil avec lequel il est associé (authentification, par exemple) sont considérés comme proches et donc distants.
  • Les bugs qui se produisent pendant le processus d'association, mais avant que le consentement de l'utilisateur (c'est-à-dire l'autorisation) n'ait été établi, sont considérés comme proches et donc distants.
  • Les bugs qui se produisent après l'obtention du consentement de l'utilisateur sont considérés comme locaux, même si l'association échoue au final.

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 accès physiquement à l'appareil, par exemple un bug sur un écran de verrouillage ou qui nécessite de brancher un câble USB. Étant donné qu'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 sont de la même gravité, que l'appareil soit 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 de 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 une fois qu'elles ont atteint leur destination finale. Par conséquent, les failles qui compromettent la sécurité réseau de la couche de liaison sont considérées comme moins graves que les failles dans HTTPS/TLS: le chiffrement Wi-Fi seul est insuffisant 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 quasi-correspondance (voir Blog des développeurs Android: Améliorations apportées à l'écran de verrouillage et à 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 classe d'attaques permet de contourner l'authentification biométrique de manière généralisable, sans 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 qu'il obtient l'accès à l'appareil en fonction des résidus laissés sur le lecteur, il s'agit d'une attaque simple qui peut être effectuée sur n'importe quel appareil susceptible d'être piraté. Aucune connaissance du propriétaire de l'appareil n'est requise. Étant donné qu'elle est généralisable et qu'elle peut potentiellement affecter un plus grand nombre d'utilisateurs, cette attaque reçoit la note de gravité maximale (par exemple, "Élevé" pour un contournement du verrouillage de l'écran).

L'autre classe d'attaques implique généralement un instrument d'attaque par 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, un contournement biométrique recevra la note de gravité maximale). Toutefois, si un pirate informatique doit acquérir des données biométriques directement auprès du propriétaire de l'appareil (par exemple, une analyse infrarouge de son visage), cette barrière est suffisamment importante 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 Tapjacking/vulnérabilité SYSTEM_ALERT_WINDOW en superposition sur un écran non critique pour la sécurité de la page BugHunter University sur les bugs sans impact sur la sécurité.

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 compte Android est destiné à être utilisé par une personne physique différente. Par exemple, vous pouvez attribuer un utilisateur invité temporaire à un ami qui emprunte le véhicule au propriétaire. Pour répondre à des cas d'utilisation comme celui-ci, les utilisateurs ont par défaut accès aux composants nécessaires à l'utilisation du véhicule, tels que les paramètres Wi-Fi et du réseau mobile.

Composant concerné

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

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

Le composant détermine également comment les utilisateurs reçoivent les mises à jour. Un bug dans le framework ou le noyau nécessite une mise à jour du micrologiciel Over The Air (OTA) 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 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 leur 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 déployé dans AOSP après la publication de l'OTA auprès des utilisateurs.

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 de l'OEM qui a produit l'appareil ou de l'opérateur qui fournit le service. Les mises à jour des appareils Google Pixel sont fournies par 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 pouvant être installées 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 une faille 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 applications pour avertir les utilisateurs des applications potentiellement dangereuses.

Autres ressources

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

Des informations de sécurité sont disponibles sur les sites Android Open Source et pour les développeurs. Voici quelques bons points de départ:

Rapports

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