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 |
|
| Haute |
|
| Modérer |
|
| Meugler |
|
| 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 é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 :
- https://source.android.com/security/index
- https://developer.android.com/training/articles/security-tips
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.