Mises à jour de sécurité et ressources

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 principales fournies avec les appareils Android.

L'équipe de sécurité Android trouve des failles de sécurité grâce à des recherches internes et répond également aux bogues signalés par des tiers. Les sources de bogues externes comprennent les problèmes signalés par le modèle de problème de sécurité Android , publié et recherche académique publication préalable, mainteneurs de projets open source en amont, les notifications de nos partenaires du fabricant de l' appareil, et les problèmes divulgués publiquement affichés sur les blogs ou les médias sociaux.

Signaler des problèmes de sécurité

Tout développeur, utilisateur Android, ou un chercheur de sécurité peut informer l'équipe de sécurité Android des problèmes de sécurité potentiels par le formulaire de déclaration 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 envisagez de soumettre un correctif ou un test de Compatibility Test Suite (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 sur AOSP.

Trier les bogues

La première tâche de gestion d'une vulnérabilité de sécurité consiste à 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 répare 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 le domaine dans lequel il s'exécute. Tous les contextes de sécurité ne sont pas applicables à tous les systèmes. Ce tableau est classé du moins privilégié 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 minimales sont fournies.

Par exemple, des « bacs à sable » d'application pour traiter des données non fiables sans autoriser l'accès au système sous-jacent.
Contexte non privilégié Un environnement d'exécution typique attendu par du code non privilégié.

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

Par exemple, une application Android avec des capacités qui serait interdit par le SELinux untrusted_app domaine ou avec accès à privileged|signature des autorisations.
Base de calcul de confiance (TCB) Fonctionnalité qui fait partie du noyau, s'exécute dans le même contexte CPU 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), les processeurs de communication, ou est l' un d'une poignée de services utilisateur qui est considéré comme noyau équivalent: apexd , bpfloader , init , ueventd et vold .
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 de confiance (TEE) Un composant conçu pour être protégé même contre un noyau hostile (par exemple, TrustZone et Hypervisor).
Enclave sécurisée / Élément sécurisé (SE) Un composant matériel optionnel destiné à être protégé de tous les autres composants de l'appareil et d' une attaque physique, tel que défini dans Introduction to éléments sécurisés .

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

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 contexte privilégié, la chaîne de bootloader, ou le TCB
  • Déni de service persistant à distance (permanent ou nécessitant un reflashage de l'ensemble du 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 d'un comportement équivalent
  • Contournement à distance des exigences d'interaction utilisateur pour tous les paramètres de développeur, de sécurité ou de confidentialité
  • Contournement de démarrage sécurisé à distance
  • Contournement des mécanismes 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 informations d'identification sensibles utilisées pour l'authentification du service à distance (par exemple, les mots de passe de compte ou les jetons de support)
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 contexte non privilégié
  • Exécution de code arbitraire local dans un contexte privilégié, la chaîne de bootloader, ou le TCB
  • Accès non autorisé aux données sécurisées par le TEE
  • Attaques contre un SE qui entraînent une rétrogradation vers une implémentation moins sécurisée
  • Contournement local des exigences d'interaction de l'utilisateur lors de l'installation du package ou d'un comportement équivalent
  • Accès à distance aux données protégées (données limitées à un contexte privilégié)
  • Déni de service local persistant (permanent ou nécessitant un reflashage de l'ensemble du système d'exploitation ou une réinitialisation d'usine)
  • Contournement à distance des exigences d'interaction de l'utilisateur (accès à des fonctionnalités ou à des données qui nécessiteraient normalement soit l'initiation de l'utilisateur, soit 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 une technologie d'atténuation d'exploit dans la chaîne du chargeur de démarrage, TEE ou SE
  • Un contournement général pour les protections du système d'exploitation qui isolent les données d'application ou les profils d'utilisateur les uns des autres
  • Contournement local des exigences d'interaction utilisateur pour tous les paramètres de développeur, de sécurité ou de confidentialité
  • Vulnérabilité cryptographique qui permet des attaques contre des protocoles de bout en bout, y compris des attaques contre la sécurité de la couche de transport (TLS) et Bluetooth (BT).
  • Contournement de l'écran de verrouillage
  • Contournement de la protection de l'appareil/protection de 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 qui sont sécurisées par le TEE
  • Prévention à distance de l'accès au service cellulaire sans interaction de l'utilisateur (par exemple, plantage du service radio cellulaire avec un paquet mal formé)
  • Accès local aux informations d'identification sensibles utilisées pour l'authentification du service à distance (par exemple, les mots de passe de compte ou les jetons de support)
Modérer
  • Exécution de code arbitraire à distance dans un contexte contraint
  • Déni de service d'un périphérique temporaire à distance (blocage ou redémarrage à distance)
  • Exécution de code arbitraire local dans un contexte non privilégié
  • Un contournement général pour une défense en profondeur ou exploiter une technologie d'atténuation dans un contexte 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 contexte privilégié)
  • Contournement local des exigences d'interaction de l'utilisateur (accès à des fonctionnalités ou à des 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
Meugler
  • Exécution de code arbitraire local dans un contexte contraint
  • Vulnérabilité cryptographique dans une utilisation non standard
  • 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é
  • Documentation incorrecte pouvant entraîner un malentendu lié à la sécurité avec des défauts de code ultérieurs
  • By - pass général de personnalisation sur l'appareil des caractéristiques telles que la voix match ou match face
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 changements 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é qui a besoin d' un système de fichiers malformés, si ce système de fichiers est toujours adopté / crypté 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 contexte 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 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 l'appareil est allumé et a déjà été déverrouillé -2 Gravité
Une attaque locale qui nécessite le déverrouillage de la chaîne de bootloader Pas plus haut que Bas
Une attaque locale qui nécessite que le mode développeur ou tout paramètre de mode développeur persistant soit actuellement activé sur l'appareil (et n'est pas un bogue dans le 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 par la navigation sur une page Web, la lecture d'un e-mail, la réception d'un message SMS ou la connexion à un réseau hostile. Aux fins de nos évaluations de gravité, nous considérons également les vecteurs d'attaque « proximaux » comme distants. Il s'agit notamment de bogues qui ne peuvent être exploités que par un attaquant qui se trouve physiquement à proximité de l'appareil cible, par exemple, un bogue qui nécessite l'envoi de paquets Wi-Fi ou Bluetooth malformés. Nous considérons les attaques ultra-large bande (UWB) et NFC comme proximales et donc distantes.

Attaques locales exigent la victime d'exécuter une application, que ce soit en installant et en exécutant une application ou en consentant à exécuter une application instantanée . Aux fins des évaluations de gravité, nous considérons également les vecteurs d'attaque physique comme locaux. Il s'agit notamment de bogues qui ne peuvent être exploités que par un attaquant qui a un accès physique à l'appareil, par exemple un bogue dans un écran de verrouillage ou qui nécessite de brancher un câble USB. Notez que les attaques qui nécessitent une connexion USB sont de 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é Internet

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 auquel il est connecté, elle ne fait rien pour sécuriser les liens 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 cryptant les données à leur source, puis en les décryptant 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 de la couche liaison sont classées moins sévères que les vulnérabilités dans 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 espace stimulant, et même les meilleurs systèmes peuvent se laisser berner par un quasi-match (voir développeurs Android Blog: améliorations lockscreen et d' authentification dans Android 11 ). Ces cotes de gravité distinguent deux classes d'attaques et sont destinées à 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 autoriser 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 qu'elle 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 l'écran de verrouillage).

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 de quelqu'un 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, un balayage infrarouge de son visage), c'est une barrière suffisamment importante pour limiter le nombre de personnes affectées par l'attaque, il y a donc un modificateur -1 .

SYSTEM_ALERT_WINDOW et Tapjacking

Pour plus d' informations sur nos politiques concernant SYSTEM_ALERT_WINDOW et tapjacking, consultez la section « Tapjacking / superposition vulnérabilité SYSTEM_ALERT_WINDOW sur un écran non-sécurité critique » de l' Université BugHunter Bugs sans impact sur la sécurité page.

Composant concerné

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 façon 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, Google Play Services ou WebView) peut être envoyé aux utilisateurs d'Android en tant que mise à jour depuis Google Play.

Partenaires notifiants

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 le backport change à chaque nouvelle version d'Android. Contactez le fabricant de votre appareil pour obtenir la liste des appareils pris en charge.

Transmettre le code à l'AOSP

Si le bogue de sécurité se trouve dans un composant AOSP, le correctif est transmis à AOSP une fois l'OTA diffusé 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 appareils via un OTA.

Recevoir les 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 du transporteur qui fournit le service à l'appareil. Les mises à jour des appareils Google Pixel proviennent de l'équipe Google Pixel après avoir suivi une procédure de test d'acceptation technique (TA) de l'opérateur. Google publie également des images d'usine Pixel qui peuvent être à des dispositifs de charge latérale.

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 qui tente d'exploiter un bogue de sécurité. Pour les applications installées à l' extérieur de Google Play, les appareils avec services Google Play peuvent également utiliser le vérifier Apps fonctionnalité pour avertir les utilisateurs sur les applications qui peuvent être potentiellement dangereux.

Autres ressources

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

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

Rapports

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