Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Mises à jour et ressources de sécurité

L'équipe de sécurité Android est responsable de la gestion des vulnérabilités de sécurité découvertes dans la plate-forme Android et de nombreuses applications Android de base fournies avec les appareils Android.

L'équipe de sécurité Android trouve des vulnérabilités de sécurité grâce à des recherches internes et répond également aux bogues signalés par des tiers. Les sources de bogues externes incluent les problèmes signalés via le modèle de problème de sécurité Android , 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 des blogs ou sur 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 rapport de vulnérabilité de sécurité .

Les bogues marqués comme des 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 de soumettre un correctif ou un test de la suite de tests de compatibilité (CTS) 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 vers AOSP.

Tri des bogues

La première tâche de la gestion d'une vulnérabilité de sécurité est d'identifier la gravité du bogue et quel composant d'Android est affecté. La gravité détermine la priorité du problème et le composant détermine qui corrige le bogue, qui est notifié et comment le correctif est déployé auprès des utilisateurs.

Types de processus

Ce tableau couvre les définitions des types de processus. Le type de processus peut être défini par le type d'application ou de processus ou la zone dans laquelle il s'exécute. Cette table est classée du moins au plus privilégié.

Type de processus Définition du type
Processus contraint Un processus qui s'exécute dans un domaine SELinux très limité.
OU
Un processus nettement plus limité qu'une application normale.
Processus sans privilège Une application ou un processus qui s'exécute dans un domaine SELinux avec l'attribut untrusted_app_all , ou est restreint de manière équivalente.
Processus privilégié Une application ou un processus avec des capacités qui seraient interdites par le domaine SELinux untrusted_app .
OU
Une application ou un processus avec des privilèges importants qu'une application tierce ne peut pas obtenir.
OU
Un composant matériel intégré sur le périphérique qui ne fait pas partie de la base informatique de confiance (TCB).
Base de calcul fiable (TCB) Fonctionnalité qui fait partie du noyau, s'exécute dans le même contexte de processeur que le noyau (comme les pilotes de périphérique), a un accès direct à la mémoire du noyau (comme les composants matériels sur le périphérique), a la capacité de charger des scripts dans un composant du noyau ( par exemple, eBPF), le processeur de bande de base ou est l'un des rares services utilisateur considérés comme équivalents au noyau: apexd , bpfloader , init , ueventd et vold .
Bootloader Un composant qui configure l'appareil au démarrage, puis passe le contrôle au système d'exploitation Android.
Environnement d'exécution sécurisé (TEE) Un composant conçu pour être protégé même contre un noyau hostile (par exemple, TrustZone et Hypervisor).
Élément sécurisé (SE) Un composant optionnel conçu pour être protégé de tous les autres composants du périphérique et des attaques physiques, comme défini dans Introduction à Secure Elements .

Gravité

La gravité d'un bogue reflète généralement les dommages potentiels qui pourraient survenir si un bogue était exploité avec succès. Utilisez les critères suivants pour déterminer la gravité.

Évaluation Conséquence d'une exploitation réussie
Critique
  • Accès non autorisé aux données sécurisées par la SE
  • Exécution de code arbitraire dans le TEE ou SE
  • Exécution de code arbitraire à distance dans un processus privilégié, un chargeur de démarrage ou le TCB
  • Déni de service permanent à distance (inopérabilité de l'appareil: complètement permanent ou nécessitant un reflasher tout le système d'exploitation ou une réinitialisation d'usine)
  • 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 tout paramètre de développeur, de sécurité ou de confidentialité
  • Contournement de démarrage sécurisé à distance
  • Contournement des mécanismes de sécurité conçus pour éviter le dysfonctionnement des composants matériels critiques (par exemple, protections thermiques)
Haute
  • Contournement de démarrage sécurisé local
  • Un contournement complet d'une fonctionnalité de sécurité de base (telle que SELinux, FDE ou seccomp)
  • Exécution de code arbitraire à distance dans un processus sans privilège
  • Exécution de code arbitraire local dans un processus privilégié, un chargeur de démarrage ou le TCB
  • Accès non autorisé aux données sécurisées par le TEE
  • Attaques contre une SE qui entraînent le passage à une implémentation moins sécurisée
  • Contournement local des exigences d'interaction de l'utilisateur lors de l'installation du package ou comportement équivalent
  • Accès à distance aux données protégées (données limitées à un processus privilégié)
  • Déni de service permanent local (inopérabilité de l'appareil: permanente ou nécessitant un reflash de tout le système d'exploitation ou une réinitialisation d'usine)
  • Contournement à distance des exigences d'interaction de l'utilisateur (accès aux fonctionnalités ou aux données qui nécessiteraient normalement le lancement ou l'autorisation de l'utilisateur)
  • Transmission d'informations sensibles via un protocole réseau non sécurisé (par exemple, HTTP et Bluetooth non crypté) lorsque le demandeur attend une transmission sécurisée (notez que cela ne s'applique pas au cryptage Wi-Fi, tel que WEP)
  • Un contournement général pour une défense en profondeur ou exploiter la technologie d'atténuation dans le bootloader, TEE ou SE
  • Contournement général des protections du système d'exploitation qui isolent les données d'application ou les profils utilisateur les uns des autres
  • Contournement local des exigences d'interaction utilisateur pour tout paramètre de développeur, de sécurité ou de confidentialité
  • Vulnérabilité cryptographique dans la sécurité de la couche de transport standard (TLS) qui permet des attaques sur chemin
  • Contournement de l'écran de verrouillage
  • Contournement de la protection de l'appareil / protection contre la réinitialisation d'usine / restrictions de l'opérateur
  • Prévention ciblée de l'accès aux services d'urgence
  • Contournement des exigences d'interaction utilisateur sécurisées par le TEE
Modérer
  • Exécution de code arbitraire à distance dans un processus contraint
  • Déni de service de périphérique temporaire à distance (blocage ou redémarrage à distance)
  • Exécution de code arbitraire local dans un processus sans privilège
  • Un contournement général pour une défense en profondeur ou exploiter une technologie d'atténuation dans un processus privilégié ou le TCB
  • Contournement des restrictions sur un processus contraint
  • Accès à distance aux données non protégées (données normalement accessibles à toute application installée localement)
  • Accès local aux données protégées (données limitées à un processus privilégié)
  • Contournement local des exigences d'interaction de l'utilisateur (accès aux fonctionnalités ou aux données qui nécessiteraient normalement soit l'initiation de l'utilisateur, soit l'autorisation de l'utilisateur)
  • Vulnérabilité cryptographique dans les primitives cryptographiques standard qui permet la fuite de texte en clair (pas les primitives utilisées dans TLS)
  • Contournement du cryptage ou de l'authentification Wi-Fi
Faible
  • Exécution de code arbitraire local dans un processus contraint
  • Vulnérabilité cryptographique dans une utilisation non standard
  • Un contournement général pour une défense au niveau de l'utilisateur en profondeur ou exploiter la technologie d'atténuation dans un processus sans privilège
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 telle sorte que la gravité effective est inférieure à Faible, bien que le problème de code sous-jacent puisse subsister
  • Toute vulnérabilité nécessitant un système de fichiers mal formé, si ce système de fichiers est toujours adopté / chiffré avant utilisation.

Modificateurs de notation

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

Raison Effet
Nécessite une exécution en tant que processus privilégié pour exécuter l'attaque -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 plate-forme 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 est toujours possible si le téléphone 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 le téléphone est allumé et a déjà été déverrouillé -2 Gravité
Une attaque locale qui nécessite le déverrouillage du bootloader Pas plus haut que bas
Une attaque locale qui nécessite l'activation du mode développeur ou de tout paramètre du mode développeur persistant sur l'appareil (et n'est pas un bogue en mode développeur lui-même). Pas plus haut que bas
Si aucun domaine SELinux ne peut effectuer l'opération sous la SEPolicy fournie par Google Impact négligeable sur la sécurité

Local versus proximal versus distant

Un vecteur d'attaque à distance indique que le bogue peut être exploité sans installer d'application ou sans accès physique à un appareil. Cela inclut les bogues qui peuvent être déclenchés en naviguant sur une page Web, en lisant un e-mail, en recevant un message SMS ou en se connectant à un réseau hostile. Aux fins de nos évaluations de gravité, l'équipe de sécurité Android considère également les vecteurs d'attaque «proximaux» comme distants. Il s'agit notamment des bogues qui ne peuvent être exploités que par un attaquant qui se trouve physiquement près de l'appareil cible, par exemple, un bogue qui nécessite l'envoi de paquets Wi-Fi ou Bluetooth mal formés. L'équipe de sécurité Android considère les attaques basées sur NFC comme proximales et donc distantes.

Les attaques locales obligent la victime à exécuter une application, soit en installant et en exécutant une application, soit en acceptant d'exécuter une application instantanée . Aux fins des évaluations de gravité, l'équipe de sécurité Android considère également les vecteurs d'attaque physiques comme locaux. Il s'agit notamment des bogues qui ne peuvent être exploités que par un attaquant ayant un accès physique à l'appareil, par exemple un bogue dans un écran de verrouillage ou un bogue qui nécessite de brancher un câble USB. Notez que les attaques qui nécessitent une connexion USB ont la même gravité, que l'appareil doive être déverrouillé ou non; il est courant que les appareils soient déverrouillés lorsqu'ils sont branchés sur USB.

Sécurité Wi-Fi

Android suppose que tous les réseaux sont hostiles et pourraient injecter des attaques ou espionner le trafic. Alors que la sécurité de la couche de liaison (par exemple, le cryptage Wi-Fi) sécurise la communication entre un appareil et le point d'accès Wi-Fi auquel il est connecté, elle ne fait rien pour sécuriser les liens restants dans 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, chiffrant les données à leur source, puis les décryptant et ne les vérifiant qu'une fois qu'elles ont atteint leur destination finale. Pour cette raison, les vulnérabilités qui compromettent la sécurité Wi-Fi sont jugées moins graves que les vulnérabilités en HTTPS / TLS: le cryptage Wi-Fi seul est insuffisant pour la plupart des communications sur Internet.

Authentification biométrique

L'authentification biométrique est un espace difficile, et même les meilleurs systèmes peuvent être trompés par une quasi-correspondance (voir Blog des développeurs Android: amélioration de l'écran de verrouillage et de l'authentification dans Android 11 ). Ces évaluations 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é du propriétaire. Si, par exemple, un attaquant peut placer un morceau de gomme sur un capteur d'empreintes digitales et qu'il accorde 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 effectuée sur n'importe quel appareil sensible. Il ne nécessite aucune connaissance du propriétaire de l'appareil. Étant donné qu'elle est généralisable et affecte potentiellement un plus grand nombre d'utilisateurs, cette attaque reçoit la cote de gravité complète (par exemple, Élevée, pour un contournement de Lockscreen).

L'autre classe d'attaques implique généralement un instrument d'attaque de présentation (spoof) 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 est suffisante pour tromper l'authentification biométrique, alors un contournement biométrique recevra la cote de gravité complète). Mais si un attaquant 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), c'est une barrière suffisamment importante pour limiter le nombre de personnes touchées par l'attaque, il y a donc un modificateur -1 .

Composant affecté

L'équipe de développement responsable de la correction du bogue dépend du composant dans lequel se trouve le bogue. Il peut s'agir d'un composant principal 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 bogue dans une application ou une bibliothèque publiée dans 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.

Aviser les partenaires

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

Libération du code vers AOSP

Si le bogue de sécurité se trouve dans un composant AOSP, le correctif est transféré vers 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 AOSP avant qu'un correctif ne soit disponible pour les périphériques via un 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 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 proviennent de l'équipe Google Pixel après avoir subi une procédure de test d'acceptation technique (TA) de l'opérateur. Google publie également des images d'usine Pixel qui peuvent être chargées sur les appareils.

Mettre à jour les 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 qui tente d'exploiter un bogue 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 qui peuvent être potentiellement dangereuses.

Autres ressources

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

Les informations de sécurité existent sur les sites Android Open Source et Developer. Bons endroits pour commencer:

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.