Ressources et mises à jour de sécurité

L’équipe de sécurité d’Android est chargée de gérer les failles de sécurité découvertes dans la plateforme Android et de nombreuses applications Android principales fournies avec des appareils Android.

L'équipe de sécurité Android détecte les failles de sécurité grâce à des recherches internes et répond aux bugs signalés par des tiers. Les bugs externes incluent les problèmes signalés via le formulaire sur les failles, recherches universitaires publiées et prépubliées, responsables de projets Open Source en amont, les notifications de nos fabricants d'appareils partenaires et les problèmes publiquement divulgué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 de d'éventuels problèmes de sécurité formulaire sur les failles.

Les bugs marqués comme des problèmes de sécurité ne sont pas visibles en externe, mais il est possible qu'ils surviennent à terme visible une fois le problème évalué ou résolu. Si vous prévoyez d'envoyer un correctif ou Test de compatibilité de la suite de tests de compatibilité (CTS) pour résoudre un problème de sécurité, veuillez le joindre au bug signaler et attendre une réponse avant d'importer le code dans AOSP.

Tri des bugs

La première tâche dans la gestion d’une vulnérabilité de sécurité consiste à identifier la gravité du bogue et quel composant d'Android est concerné. La gravité détermine la hiérarchisation du problème, Le composant détermine qui corrige le bug, qui est averti et comment le correctif est déployé. aux 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 est exécuté. Non tous les contextes de sécurité sont applicables à tous les systèmes. Ce tableau est classé du plus petit au plus grand être privilégié.

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

Par exemple, des applications de confiance traitant des données non fiables dans un environnement de bac à sable environnement.
Contexte non privilégié Environnement d'exécution typique attendu par un code non privilégié.

Par exemple, une application Android qui s'exécute dans un domaine SELinux avec le untrusted_app_all.
Contexte privilégié Un environnement d’exécution privilégié qui peut avoir accès à des autorisations élevées, gère et/ou préserve l'intégrité du système.

Par exemple, une application Android dont les fonctionnalités sont interdites par le domaine SELinux untrusted_app ou ayant accès à Autorisations privileged|signature.
Noyau de l'OS Fonctionnalité qui: <ph type="x-smartling-placeholder">
    </ph>
  • fait partie du noyau
  • s'exécute dans le même contexte de processeur que le noyau (pilotes de périphériques, par exemple).
  • Dispose d'un accès direct à la mémoire du noyau (par exemple, aux composants matériels de l'appareil)
  • peut charger des scripts dans un composant du noyau (par exemple, eBPF) ;
  • fait partie des quelques services utilisateur considérés comme équivalents au noyau (tels que apexd, bpfloader, init, ueventd et vold).
Base matérielle fiable (THB) Composants matériels distincts, généralement sur le SoC, qui offrent des fonctionnalités essentielles aux principaux cas d'utilisation de l'appareil (bandes de base cellulaires, DSP, GPU, processeurs).
Chaîne de bootloader Composant qui configure l'appareil au démarrage, puis passe le contrôle à l'OS Android.
Environnement d'exécution sécurisé (TEE) Composant conçu pour être protégé contre même un noyau de système d'exploitation hostile (par exemple, TrustZone et hyperviseurs, tels que pKVM, qui protègent les machines virtuelles du système d'exploitation noyau).
Secure Enclave / Composant sécurisé (SE) Composant matériel en option conçu pour être protégé contre tous les autres composants du et contre les attaques physiques, comme défini dans Présentation des composants 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ées avec succès. Déterminez le niveau de gravité à l'aide des critères suivants.

Rating Les conséquences d'une exploitation réussie
Critique
  • Exécution de code arbitraire dans le TEE ou le SE
  • Contournement de mécanismes logiciels conçus pour empêcher les logiciels ou le matériel liés à la sécurité les composants contre tout dysfonctionnement (par exemple, des protections thermiques).
  • Accès à distance aux identifiants sensibles utilisés pour l'authentification du service à distance (par exemple, mots de passe de compte ou jetons de support, par exemple)
  • Exécution de code arbitraire à distance dans le contexte de bande de base cellulaire sans utilisateur interaction (par exemple, exploitation d'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 de l'utilisateur lors de l'installation d'un package ou équivalent comportement
  • Contournement à distance des exigences d'interaction utilisateur pour le développeur principal, paramètres de confidentialité
  • Déni de service distant persistant (permanent, nécessitant une reflashage de l'intégralité système d'exploitation ou 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 le SE, y compris les accès rendus possibles 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).
  • Contournement général d’une technologie de défense en profondeur ou d’atténuation des exploits dans le chaîne bootloader, TEE ou SE
  • Contournement général pour les 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 le passage à une implémentation moins sécurisée
  • Pivot à partir d'un micrologiciel bare metal compromis accessible à distance (par exemple, bande de base, processeur de communication) dans le noyau du processeur d'application (AP) ou de contourner conçus pour isoler le micrologiciel Bare Metal du noyau du point d'accès
  • Contourner la protection de l'appareil/la protection après rétablissement de la configuration d'usine/les restrictions de l'opérateur
  • Contournement des exigences d'interaction utilisateur qui sont sécurisées par le TEE
  • Vulnérabilité cryptographique qui permet 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 du service à distance (par exemple, mots de passe de compte ou jetons de support, par exemple)
  • l'exécution de code arbitraire local dans un contexte privilégié, dans 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 principales exigences de développement, de sécurité ou de confidentialité paramètres
  • Contournement local des exigences d'interaction utilisateur lors de l'installation de packages ou équivalent comportement
  • Déni de service local persistant (permanent, nécessitant une remise à niveau de l'ensemble système d'exploitation ou rétablissement de la configuration d'usine)
  • Accès à distance aux données protégées (c'est-à-dire aux données limitées à un niveau le contexte)
  • Exécution de code arbitraire à distance dans un contexte non privilégié
  • Prévention à distance de l'accès aux services mobiles ou Wi-Fi sans interaction de l'utilisateur (par exemple : plantage du service de radio mobile avec un paquet incorrect)
  • Contournement à distance des exigences d'interaction de l'utilisateur (accès à des fonctionnalités ou à des données qui doit nécessiter une initiation ou une autorisation de l'utilisateur)
  • Prévention ciblée de l'accès aux services d'urgence
  • La 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. Remarque que cela ne s'applique pas au chiffrement Wi-Fi (WEP, par exemple).
  • Accès non autorisé aux données sécurisées par le TEE, y compris les accès rendus possibles par des clés faibles dans le TEE
Modérée
  • Contournement général d’une technologie de défense en profondeur ou d’atténuation des exploits dans un le contexte privilégié, le THB ou le noyau du système d’exploitation
  • Un contournement général pour les protections du système d'exploitation qui révèlent l'état du processus ou métadonnées au-delà des limites de l'application, de l'utilisateur ou du profil
  • Contournement du chiffrement ou de l'authentification Wi-Fi
  • Faille cryptographique dans les primitives cryptographiques standard, qui permet la fuite de texte brut (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 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écessiterait normalement soit une initiation de l'utilisateur, soit une autorisation de l'utilisateur)
  • Accès à distance aux données non protégées (c'est-à-dire aux données normalement accessibles localement application installée)
  • Exécution de code arbitraire à distance dans un contexte contraint
  • Déni de service temporaire de l'appareil distant (blocage ou redémarrage à distance)
Basse
  • Un contournement général pour une technologie de défense en profondeur au niveau de l’utilisateur ou d’atténuation des exploits dans un contexte non privilégié
  • Contournement d'une voie normale niveau de protection autorisation
  • Faille cryptographique dans une utilisation non standard
  • Contournement général des fonctionnalités de personnalisation sur l'appareil telles que 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 un faux 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 classification ou les modifications de l'architecture spécifique à la version de sorte que la gravité effective est inférieure à Faible, bien que le problème de code sous-jacent
  • Toute faille nécessitant un système de fichiers incorrect, si celui-ci est toujours adoptées/chiffrées avant utilisation.
  • <ph type="x-smartling-placeholder"></ph> Déni de service temporaire local, par exemple lorsqu'il est possible de résoudre le problème en redémarrant l'appareil ou en le désinstallant l'application de déclenchement.

Modificateurs de note

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 une exécution en tant que contexte privilégié pour exécuter l'attaque (non applicable aux TEE, SE, et les 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 auprès 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 niveau modéré ou supérieur
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 précédemment a été déverrouillé -2 Gravité
Attaque locale qui nécessite le déverrouillage de la chaîne du bootloader Pas supérieure à Faible
Une attaque locale qui nécessite le mode développeur ou tout paramètre persistant du mode développeur pour doit être activé sur l'appareil (il ne s'agit pas d'un bug du mode développeur). Pas supérieure à Faible
Si aucun domaine SELinux ne peut effectuer l'opération conformément à la règle SEPolicy fournie par Google, Impact négligeable sur la sécurité
<ph type="x-smartling-placeholder">

Local, proximaux ou distants

Un vecteur d'attaque distant 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 en accédant une page Web, la lecture d'un e-mail, la réception d'un SMS ou la connexion à un réseau hostile.

Les vecteurs d'attaque proximaux sont considérés comme distants. Il peut s'agir de bugs uniquement pouvant être exploités par un attaquant qui se trouve physiquement à proximité de l'appareil cible, par exemple, un bogue qui nécessite envoyant des paquets Wi-Fi ou Bluetooth mal formés. Nous prenons en compte la bande ultralarge (UWB) et la technologie NFC les attaques proximales et donc à distance.

Les attaques locales nécessitent que l’attaquant ait un accès préalable à la victime. Dans un scénario logiciel uniquement, il peut s'agir d'une application malveillante installée par la victime ou d'une l'appli instantanée dont ils disposent a accepté d'être diffusée.

Les appareils associés correctement (tels que les appareils Bluetooth associés) sont considérés comme locaux. Mer faire la distinction entre un appareil associé et un appareil participant à une association le flux de travail.

  • Les bugs qui empêchent l'utilisateur d'identifier l'autre appareil associé (par exemple, authentification) sont considérés comme proximaux et donc distants.
  • Bugs qui se produisent pendant le flux d'association, mais avant que l'utilisateur n'ait donné son consentement (autorisation) sont considérés comme proximaux 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 finalement.

Les vecteurs d'attaque physiques sont considérés comme locaux. Il s'agit notamment de bugs qui ne peuvent être exploités que un pirate informatique qui a un accès physique à l'appareil, par exemple un bug dans un écran de verrouillage ou un qui nécessite de brancher un câble USB. Étant donné qu’il est courant que les appareils soient déverrouillés pendant branché sur USB, les attaques qui nécessitent une connexion USB sont de la même gravité, quelle que soit si l'appareil doit être déverrouillé ou non.

Sécurité réseau

Android part du principe que tous les réseaux sont hostiles et pourraient injecter des attaques ou espionner du trafic. Alors 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é, il ne fait rien pour sécuriser 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, en chiffrant les données à sa source, puis le déchiffrer et le vérifier uniquement une fois qu’il a atteint sa destination finale. Pour cette raison, les vulnérabilités qui compromettent la sécurité réseau de la couche de liaison sont évaluées moins plus grave que les failles dans HTTPS/TLS. Le chiffrement Wi-Fi seul est insuffisant pour la plupart 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 un correspondance partielle (voir Blog des développeurs Android: Améliorations apportées à l'écran de verrouillage et à l'authentification dans Android 11. Ces niveaux de gravité font la distinction entre deux classes d'attaques et sont destinées à refléter le risque réel pour l’utilisateur final.

La première catégorie d’attaques permet de contourner l’authentification biométrique d’une manière généralisable, sans données biométriques de haute qualité de la part du propriétaire. Si, par exemple, un pirate informatique peut placer un de chewing-gum sur un lecteur d'empreinte digitale, ce qui lui permet d'accéder à l'appareil en fonction des résidus de chewing-gum sur le capteur, il s'agit d'une simple attaque 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'il peut être généralisable et peut affecter un plus grand nombre d'utilisateurs, cette attaque reçoit le niveau de gravité complet (par exemple, "Élevée" pour ignorer l'écran de verrouillage).

L'autre type d'attaques implique généralement un instrument d'attaque de présentation (spoof) basé sur sur le propriétaire de l'appareil. Parfois, ces informations biométriques sont relativement faciles à obtenir (pour 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 reçoit le niveau de gravité complet). Mais si un attaquant aurait besoin d'obtenir des données biométriques directement auprès du propriétaire de l'appareil (par exemple, un scan infrarouge leur visage), cela constitue un obstacle suffisamment important pour limiter le nombre de personnes touchées par l'attaque, il y a donc un modificateur -1.

SYSTEM_ALERT_WINDOW et tapjacking

Pour en savoir plus sur nos règles concernant SYSTEM_ALERT_WINDOW et le tapjacking, Consultez le message "Tapjacking/overlay SYSTEM_ALERT_WINDOW Vulnerability on a non-security-security screen" du programme de l'université BugHunter 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 utilisateur Android est destiné à être utilisé par une personne physique. Par exemple, un utilisateur invité temporaire peut être affecté à un ami qui emprunte le véhicule du propriétaire de la voiture. Pour répondre à de tels cas d'utilisation, les utilisateurs ont par défaut L'accès aux composants nécessaires à l'utilisation du véhicule, tels que les réseaux Wi-Fi et mobiles paramètres.

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 noyau fourni par un fabricant d'équipement (OEM) ou l'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. Bugs de faible gravité, bugs dans certains composants ou bugs déjà connus du grand public peuvent être corrigés directement branche principale AOSP accessible au public ; sinon ils sont corrigés dans nos référentiels internes. en premier.

Le composant est également pris en compte dans 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 Over The Air (OTA) que chaque OEM doit déployer. Un bogue dans une application ou bibliothèque publiée dans Google Play (par exemple, Gmail, les services Google Play ou WebView) peuvent être envoyées aux utilisateurs d'Android sous forme de mise à jour de Google Play.

Notification des partenaires

Lorsqu'une faille de sécurité dans AOSP est corrigée dans un bulletin de sécurité Android, nous en informons Les partenaires Android fournissent des détails sur les problèmes et fournissent des correctifs. La liste des versions compatibles avec le rétroportage à chaque nouvelle version d'Android. Contactez le fabricant de votre appareil pour obtenir la liste des appareils compatibles.

Publication du code sur AOSP

Si le bug de sécurité se trouve dans un composant AOSP, le correctif est envoyé à AOSP après l'OTA sont mises à la disposition des utilisateurs. Les corrections pour les problèmes de faible gravité peuvent être envoyées directement à 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 distribuées aux appareils via des packages de mise à jour OTA. Ces mises à jour peuvent provenir de l'OEM qui a fabriqué l'appareil ou de l'opérateur qui les fournit à l'appareil. Les mises à jour des appareils Google Pixel sont transmises par l'équipe Google Pixel après par le biais d'une procédure de test d'acceptation technique par l'opérateur. Google publie aussi Images d'usine Pixel téléchargée indépendamment sur les appareils.

Mise à jour des services Google...

En plus de fournir des correctifs pour les bugs de sécurité, l'équipe de sécurité Android examine les bogues afin de déterminer s’il existe d’autres moyens de protéger les utilisateurs. Par exemple, Google Play analyse tous applications et supprime toute application tentative d'exploiter un bug de sécurité. Pour les applications installées depuis en dehors de Google Play, les appareils équipés des services Google Play peuvent également utiliser d'avertissement via la fonctionnalité Vérifier les applications. les utilisateurs à propos des applications potentiellement dangereuses.

Autres ressources

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

Les informations sur la sécurité sont disponibles sur les sites Android Open Source et pour les développeurs. Satisfaisante points de départ:

Rapports

Il arrive que l'équipe de sécurité Android publie des rapports ou des livres blancs. Voir Consultez les rapports de sécurité pour en savoir plus.