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 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 incluent les problèmes signalés via le formulaire de vulnérabilité , les recherches universitaires publiées et prépubliées, les mainteneurs de projets open source en amont, les notifications de nos partenaires fabricants d'appareils et les problèmes divulgués publiquement publié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 des problèmes de sécurité potentiels via le formulaire de vulnérabilité .
Les bogues marqués comme problèmes de sécurité ne sont pas visibles de l'extérieur, mais ils peuvent éventuellement être rendus visibles après l'évaluation ou la résolution du problème. Si vous prévoyez de soumettre un correctif ou un test CTS (Compatibility Test Suite) 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 dans la 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 hiérarchisation 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 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 la zone dans laquelle il s'exécute. Tous les contextes de sécurité ne sont pas applicables à tous les systèmes. Cette table est classée 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 applications approuvées traitant des données non approuvées dans un environnement en bac à sable. |
| Contexte non privilégié | Un environnement d'exécution typique attendu par du 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é | Un environnement d'exécution privilégié qui peut avoir accès à des autorisations élevées, gérer plusieurs PII 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 un accès aux autorisations privileged|signature . |
| Noyau du système d'exploitation | Fonctionnalité qui :
|
| Base matérielle de confiance (THB) | Composants matériels discrets, 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 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 de système d'exploitation hostile (par exemple, TrustZone et des hyperviseurs, tels que pKVM, qui protègent les machines virtuelles du noyau de système d'exploitation). |
| Enclave sécurisée / élément 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 aux éléments sécurisés . Cela inclut la puce Titan-M présente dans certains appareils Android. |
Gravité
La gravité d'un bogue reflète généralement le préjudice potentiel qui pourrait survenir si un bogue était exploité avec succès. Utilisez les critères suivants pour déterminer la gravité.
| Notation | Conséquence d'une exploitation réussie |
|---|---|
| Critique |
|
| Haut |
|
| Modéré |
|
| Faible |
|
| Impact négligeable sur la sécurité (NSI) |
|
Modificateurs de notation
Bien que la gravité des vulnérabilités de sécurité soit souvent facile à identifier, les notes peuvent changer en fonction des circonstances.
| Raison | Effet |
|---|---|
| Nécessite une exécution en tant que contexte privilégié pour exécuter l'attaque (non applicable à TEE, SE et aux 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 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 éléments 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 du 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 dans le cadre de SEPolicy fourni 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 bugs 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 cotes 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 basées sur l'ultra large bande (UWB) et 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 consentant à exécuter une application instantanée . Les appareils compagnons couplés seront considérés comme locaux. Aux fins des cotes de gravité, l'équipe de sécurité Android considère également les vecteurs d'attaque physique comme locaux. Il s'agit notamment de 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 qui nécessite de brancher un câble USB.
Sécurité Internet
Android suppose que tous les réseaux sont hostiles et pourraient injecter des attaques ou espionner le trafic. Bien 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 dans 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 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. Pour cette raison, les vulnérabilités qui compromettent la sécurité du réseau de la couche de liaison sont jugées moins graves que les vulnérabilités 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 difficile, et même les meilleurs systèmes peuvent être trompés par une quasi-correspondance (voir Blog des développeurs Android : Écran de verrouillage et améliorations de l'authentification dans Android 11 ). Ces cotes 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 autorise 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 (usurpation) 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, un contournement biométrique recevrait 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 scan 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 de -1 .
SYSTEM_ALERT_WINDOW et Tapjacking
Pour plus d'informations sur nos politiques concernant SYSTEM_ALERT_WINDOW et le tapjacking, consultez la section " Tapjacking/overlay SYSTEM_ALERT_WINDOW sur un écran non critique pour la sécurité " de la page Bugs sans impact sur la sécurité de l'Université BugHunter.
Sécurité multi-utilisateurs 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 de la voiture. Pour s'adapter à de tels cas d'utilisation, 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 de réseau cellulaire.
Composant concerné
L'équipe de développement chargée de corriger le bogue dépend du composant dans lequel se trouve le bogue. Il peut s'agir d'un composant central 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 de 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 dépôts 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 en direct (OTA) 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 sous forme de mise à jour depuis Google Play.
Aviser 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 prises en charge par le rétroportage change à chaque nouvelle version d'Android. Contactez le fabricant de votre appareil pour obtenir la liste des appareils pris en charge.
Transmission du code à AOSP
Si le bogue de sécurité se trouve dans un composant AOSP, le correctif est transmis à AOSP après la publication de l'OTA pour les 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 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 été soumises à 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 latéralement sur les appareils.
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 en dehors de Google Play, les appareils dotés des services Google Play peuvent également utiliser la fonction Vérifier les applications pour avertir les utilisateurs des applications 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 :
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
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.