Mise en œuvre de la sécurité

L'équipe de sécurité Android reçoit régulièrement des demandes d'informations sur la prévention des problèmes de sécurité potentiels sur les appareils Android. Nous vérifions également occasionnellement les appareils et informons les fabricants d'appareils et les partenaires concernés des problèmes potentiels.

Cette page fournit les meilleures pratiques de sécurité basées sur nos expériences, étendant la documentation Designing for Security que nous avons fournie aux développeurs et inclut des détails propres à la création ou à l'installation de logiciels au niveau système sur les appareils.

Pour faciliter l'adoption de ces bonnes pratiques, lorsque cela est possible, l'équipe de sécurité Android intègre des tests dans Android Compatibility Test Suite (CTS) et Android Lint . Nous encourageons les implémenteurs d'appareils à contribuer à des tests qui peuvent aider d'autres utilisateurs d'Android (consultez les tests liés à la sécurité sur root/cts/tests/tests/security/src/android/security/cts ).

Processus de développement

Utilisez les bonnes pratiques suivantes dans vos processus et environnement de développement.

Révision du code source

L'examen du code source peut détecter un large éventail de problèmes de sécurité, y compris ceux identifiés dans ce document. Android encourage fortement la révision manuelle et automatisée du code source. Les meilleures pratiques:

• Exécutez Android Lint sur tout le code d'application à l'aide du SDK Android et corrigez tous les problèmes identifiés.
• Le code natif doit être analysé à l'aide d'un outil automatisé capable de détecter les problèmes de gestion de la mémoire tels que les débordements de mémoire tampon et les erreurs ponctuelles.
• Le système de construction Android prend en charge de nombreux désinfectants LLVM, tels que AddressSanitizer et UndefinedBehaviorSanitizer, qui peuvent être utilisés à cette fin.

Utiliser des tests automatisés

Les tests automatisés peuvent détecter un large éventail de problèmes de sécurité, notamment plusieurs problèmes abordés ci-dessous. Les meilleures pratiques:

• CTS est régulièrement mis à jour avec des tests de sécurité ; exécutez la version la plus récente de CTS pour vérifier la compatibilité.
• Exécutez CTS régulièrement tout au long du processus de développement pour détecter les problèmes plus tôt et réduire le temps de correction. Android utilise CTS dans le cadre d'une intégration continue dans notre processus de génération automatisé, qui est généré plusieurs fois par jour.
• Les fabricants d’appareils devraient automatiser les tests de sécurité des interfaces, y compris les tests avec des entrées mal formées (fuzz testing).

Images du système de signature

La signature de l'image système est essentielle pour déterminer l'intégrité du périphérique. Les meilleures pratiques:

• Les appareils ne doivent pas être signés avec une clé publiquement connue.
• Les clés utilisées pour signer les appareils doivent être gérées d'une manière conforme aux pratiques standard de l'industrie en matière de gestion des clés sensibles, y compris un module de sécurité matériel (HSM) qui fournit un accès limité et vérifiable.

Signature d'applications (APK)

Les signatures d'application jouent un rôle important dans la sécurité des appareils et sont utilisées pour les vérifications d'autorisations ainsi que pour les mises à jour logicielles. Lors de la sélection d'une clé à utiliser pour signer des applications, il est important de déterminer si une application sera disponible uniquement sur un seul appareil ou si elle sera commune à plusieurs appareils. Les meilleures pratiques:

• Les candidatures ne doivent pas être signées avec une clé publiquement connue.
• Les clés utilisées pour signer les applications doivent être gérées d'une manière conforme aux pratiques standard de l'industrie en matière de gestion des clés sensibles, y compris un HSM qui fournit un accès limité et vérifiable.
• Les candidatures ne doivent pas être signées avec la clé de plateforme.
• Les applications portant le même nom de package ne doivent pas être signées avec des clés différentes. Cela se produit souvent lors de la création d’une application pour différents appareils, notamment lors de l’utilisation de la clé de plateforme. Si l'application est indépendante du périphérique, utilisez la même clé sur tous les appareils. Si l'application est spécifique à un appareil, créez des noms de package uniques par appareil et par clé.

Publication d'applications

Google Play offre aux fabricants d'appareils la possibilité de mettre à jour les applications sans effectuer une mise à jour complète du système. Cela peut accélérer la réponse aux problèmes de sécurité et la livraison de nouvelles fonctionnalités, ainsi que fournir un moyen de garantir que votre application dispose d'un nom de package unique. Les meilleures pratiques:

• Téléchargez vos applications sur Google Play pour autoriser les mises à jour automatiques sans nécessiter une mise à jour complète en direct (OTA). Les applications téléchargées mais non publiées ne sont pas directement téléchargeables par les utilisateurs mais les applications sont toujours mises à jour. Les utilisateurs qui ont déjà installé l'application peuvent la réinstaller et/ou l'installer sur d'autres appareils.
• Créez un nom de dossier de candidature clairement associé à votre entreprise, par exemple en utilisant la marque de l'entreprise.
• Les applications publiées par les fabricants d'appareils doivent être téléchargées sur le Google Play Store pour éviter l'usurpation du nom du package par des utilisateurs tiers. Si un fabricant d'appareil installe une application sur un appareil sans publier l'application sur le Play Store, un autre développeur peut télécharger la même application, utiliser le même nom de package et modifier les métadonnées de l'application. Lorsque l’application est présentée à l’utilisateur, ces métadonnées sans rapport pourraient créer de la confusion.

Répondre aux incidents

Les parties externes doivent avoir la possibilité de contacter les fabricants d'appareils au sujet des problèmes de sécurité spécifiques aux appareils. Nous vous recommandons de créer une adresse e-mail accessible au public pour gérer les incidents de sécurité. Les meilleures pratiques:

• Créez une adresse [e-mail] ou similaire et publiez-la.
• Si vous prenez conscience d'un problème de sécurité affectant le système d'exploitation Android ou les appareils Android de plusieurs fabricants d'appareils, vous devez contacter l'équipe de sécurité Android en déposant un rapport de bogue de sécurité .

Mise en œuvre du produit

Utilisez les bonnes pratiques suivantes lors de la mise en œuvre d’un produit.

Isoler les processus racine

Les processus racine sont la cible la plus fréquente des attaques d’élévation de privilèges, donc réduire le nombre de processus racine réduit le risque d’élévation de privilèges. CTS comprend un test informatif qui répertorie les processus racine. Les meilleures pratiques:

• Les appareils doivent exécuter le code minimum nécessaire en tant que root. Dans la mesure du possible, utilisez un processus Android classique plutôt qu'un processus racine. L'ICS Galaxy Nexus n'a que six processus racine : vold, inetd, zygote, tf_daemon, ueventd et init. Si un processus doit s'exécuter en tant que root sur un appareil, documentez le processus dans une demande de fonctionnalité AOSP afin qu'il puisse être examiné publiquement.
• Dans la mesure du possible, le code racine doit être isolé des données non fiables et accessible via IPC. Par exemple, réduisez la fonctionnalité racine à un petit service accessible via Binder et exposez le service avec une autorisation de signature à une application avec peu ou pas de privilèges pour gérer le trafic réseau.
• Les processus racine ne doivent pas écouter sur un socket réseau.
• Les processus racine ne doivent pas fournir un environnement d'exécution à usage général pour les applications (par exemple, une machine virtuelle Java).

Isoler les applications système

En général, les applications préinstallées ne doivent pas s'exécuter avec l'UID du système partagé. Toutefois, s'il est nécessaire qu'une application utilise l'UID partagé du système ou un autre service privilégié, l'application ne doit exporter aucun service, récepteur de diffusion ou fournisseur de contenu accessible aux applications tierces installées par les utilisateurs. Les meilleures pratiques:

• Les appareils doivent exécuter le code minimum nécessaire en tant que système. Dans la mesure du possible, utilisez un processus Android avec son propre UID plutôt que de réutiliser l'UID du système.
• Dans la mesure du possible, le code système doit être isolé des données non fiables et exposer IPC uniquement à d'autres processus fiables.
• Les processus système ne doivent pas écouter sur une socket réseau.

Processus d'isolation

Le bac à sable d'application Android fournit aux applications une attente d'isolation des autres processus du système, y compris les processus racine et les débogueurs. À moins que le débogage ne soit spécifiquement activé par l’application et l’utilisateur, aucune application ne doit violer cette attente. Les meilleures pratiques:

• Les processus racine ne doivent pas accéder aux données contenues dans des dossiers de données d'application individuels, sauf en utilisant une méthode de débogage Android documentée.
• Les processus racine ne doivent pas accéder à la mémoire des applications, sauf en utilisant une méthode de débogage Android documentée.
• Les appareils ne doivent inclure aucune application accédant aux données ou à la mémoire d’autres applications ou processus.

Sécurisation des fichiers SUID

Les nouveaux programmes setuid ne doivent pas être accessibles par des programmes non fiables. Les programmes Setuid ont souvent été l'emplacement de vulnérabilités qui peuvent être utilisées pour obtenir un accès root, alors efforcez-vous de minimiser la disponibilité du programme setuid pour les applications non fiables. Les meilleures pratiques:

• Les processus SUID ne doivent pas fournir de shell ou de porte dérobée pouvant être utilisée pour contourner le modèle de sécurité Android.
• Les programmes SUID ne doivent être accessibles en écriture par aucun utilisateur.
• Les programmes SUID ne doivent pas être lisibles ou exécutables par tout le monde. Créez un groupe, limitez l'accès au binaire SUID aux membres de ce groupe et placez toutes les applications qui devraient pouvoir exécuter le programme SUID dans ce groupe.
• Les programmes SUID sont une source courante d’enracinement des appareils par les utilisateurs. Pour réduire ce risque, les programmes SUID ne doivent pas être exécutables par l'utilisateur du shell.

Le vérificateur CTS comprend un test informatif répertoriant les fichiers SUID ; certains fichiers setuid ne sont pas autorisés par les tests CTS.

Sécuriser les prises d'écoute

Les tests CTS échouent lorsqu'un périphérique écoute sur n'importe quel port, sur n'importe quelle interface. En cas de panne, Android vérifie que les bonnes pratiques suivantes sont utilisées :

• Il ne devrait y avoir aucun port d'écoute sur l'appareil.
• Les ports d'écoute doivent pouvoir être désactivés sans OTA. Il peut s'agir d'un changement de configuration du serveur ou de l'appareil utilisateur.
• Les processus racine ne doivent écouter sur aucun port.
• Les processus appartenant à l'UID du système ne doivent écouter sur aucun port.
• Pour un IPC local utilisant des sockets, les applications doivent utiliser un socket de domaine UNIX avec un accès limité à un groupe. Créez un descripteur de fichier pour l'IPC et définissez-le +RW pour un groupe UNIX spécifique. Toutes les applications clientes doivent appartenir à ce groupe UNIX.
• Certains appareils dotés de plusieurs processeurs (par exemple une radio/modem séparé du processeur d'application) utilisent des sockets réseau pour communiquer entre les processeurs. Dans de tels cas, le socket réseau utilisé pour la communication entre processeurs doit utiliser une interface réseau isolée pour empêcher l'accès des applications non autorisées sur l'appareil (c'est-à-dire utiliser iptables pour empêcher l'accès d'autres applications sur l'appareil).
• Les démons qui gèrent les ports d'écoute doivent être robustes contre les données mal formées. Google peut effectuer des tests de fuzz sur le port en utilisant un client non autorisé et, si possible, un client autorisé. Tout crash sera classé comme un bug avec une gravité appropriée.

Données d'enregistrement

La journalisation des données augmente le risque d’exposition de ces données et réduit les performances du système. Plusieurs incidents de sécurité publique se sont produits à la suite de la journalisation de données utilisateur sensibles par des applications installées par défaut sur les appareils Android. Les meilleures pratiques:

• Les applications ou les services système ne doivent pas enregistrer les données fournies par des applications tierces susceptibles d'inclure des informations sensibles.
• Les applications ne doivent enregistrer aucune information personnelle identifiable (PII) dans le cadre d’un fonctionnement normal.

CTS comprend des tests qui vérifient la présence d'informations potentiellement sensibles dans les journaux système.

Limitation de l'accès aux répertoires

Les répertoires accessibles en écriture universelle peuvent introduire des failles de sécurité et permettre à une application de renommer des fichiers approuvés, de les remplacer ou de mener des attaques basées sur des liens symboliques (les attaquants peuvent utiliser un lien symbolique vers un fichier pour inciter un programme fiable à effectuer des actions qu'il ne devrait pas). Les répertoires inscriptibles peuvent également empêcher la désinstallation d'une application de nettoyer correctement tous les fichiers associés à une application.

Il est recommandé que les répertoires créés par le système ou les utilisateurs root ne soient pas accessibles en écriture par tout le monde. Les tests CTS aident à appliquer cette bonne pratique en testant les répertoires connus.

Sécuriser les fichiers de configuration

De nombreux pilotes et services s'appuient sur des fichiers de configuration et de données stockés dans des répertoires tels que /system/etc et /data . Si ces fichiers sont traités par un processus privilégié et sont accessibles en écriture par tout le monde, il est possible qu'une application exploite une vulnérabilité du processus en créant du contenu malveillant dans le fichier accessible en écriture par tout le monde. Les meilleures pratiques:

• Les fichiers de configuration utilisés par les processus privilégiés ne doivent pas être lisibles par tout le monde.
• Les fichiers de configuration utilisés par les processus privilégiés ne doivent pas être accessibles en écriture par tout le monde.

Stockage des bibliothèques de codes natifs

Tout code utilisé par les processus privilégiés du fabricant de périphériques doit être dans /vendor ou /system ; ces systèmes de fichiers sont montés en lecture seule au démarrage. À titre de bonne pratique, les bibliothèques utilisées par le système ou d'autres applications hautement privilégiées installées sur l'appareil doivent également se trouver dans ces systèmes de fichiers. Cela peut empêcher une vulnérabilité de sécurité qui pourrait permettre à un attaquant de contrôler le code exécuté par un processus privilégié.

Limitation de l'accès au pilote de périphérique

Seul le code fiable doit avoir un accès direct aux pilotes. Dans la mesure du possible, l'architecture préférée consiste à fournir un démon à usage unique qui transmet les appels au pilote et restreint l'accès du pilote à ce démon. En tant que bonne pratique, les nœuds de périphérique de pilote ne doivent pas être lisibles ni accessibles en écriture par tout le monde. Les tests CTS aident à appliquer cette bonne pratique en vérifiant les instances connues de pilotes exposés.

Désactivation de la BAD

Le pont de débogage Android (adb) est un outil de développement et de débogage précieux, mais il est conçu pour être utilisé dans des environnements contrôlés et sécurisés et ne doit pas être activé pour un usage général. Les meilleures pratiques:

• ADB doit être désactivé par défaut.
• ADB doit demander à l'utilisateur de l'activer avant d'accepter les connexions.

Déverrouillage des chargeurs de démarrage

De nombreux appareils Android prennent en charge le déverrouillage, permettant au propriétaire de l'appareil de modifier la partition système et/ou d'installer un système d'exploitation personnalisé. Les cas d'utilisation courants incluent l'installation d'une ROM tierce et l'exécution d'un développement au niveau du système sur l'appareil. Par exemple, le propriétaire d'un appareil Google Nexus peut exécuter fastboot oem unlock pour démarrer le processus de déverrouillage, ce qui présente le message suivant à l'utilisateur :

Débloquer le bootloader ?

Si vous déverrouillez le chargeur de démarrage, vous pourrez installer un logiciel de système d'exploitation personnalisé sur cet appareil.

Un système d'exploitation personnalisé n'est pas soumis aux mêmes tests que le système d'exploitation d'origine et peut empêcher votre appareil et les applications installées de fonctionner correctement.

Pour empêcher tout accès non autorisé à vos données personnelles, le déverrouillage du chargeur de démarrage supprimera également toutes les données personnelles de votre appareil (une « réinitialisation des données d'usine »).

Appuyez sur les boutons d'augmentation/réduction du volume pour sélectionner Oui ou Non. Appuyez ensuite sur le bouton d'alimentation pour continuer.

Oui : Déverrouillez le chargeur de démarrage (peut annuler la garantie)

Non : ne déverrouillez pas le chargeur de démarrage et ne redémarrez pas l'appareil.

En tant que bonne pratique, les appareils Android déverrouillables doivent effacer en toute sécurité toutes les données utilisateur avant d'être déverrouillés. Le fait de ne pas supprimer correctement toutes les données lors du déverrouillage peut permettre à un attaquant physiquement proche d'obtenir un accès non autorisé aux données confidentielles des utilisateurs Android. Pour empêcher la divulgation des données utilisateur, un appareil prenant en charge le déverrouillage doit l'implémenter correctement (nous avons vu de nombreux cas où les fabricants d'appareils ont mal implémenté le déverrouillage). Un processus de déverrouillage correctement mis en œuvre a les propriétés suivantes :

• Lorsque la commande de déverrouillage est confirmée par l'utilisateur, l'appareil doit lancer un effacement immédiat des données. L’indicateur unlocked ne doit pas être activé avant la fin de la suppression sécurisée.
• Si une suppression sécurisée ne peut pas être effectuée, l'appareil doit rester dans un état verrouillé.
• S'il est pris en charge par le périphérique de bloc sous-jacent, ioctl(BLKSECDISCARD) ou équivalent doit être utilisé. Pour les appareils eMMC, cela signifie utiliser une commande Secure Erase ou Secure Trim. Pour eMMC 4.5 et versions ultérieures, cela signifie utiliser un effacement ou un découpage normal suivi d'une opération de désinfection.
• Si BLKSECDISCARD n'est pas pris en charge par le périphérique de bloc sous-jacent, ioctl(BLKDISCARD) doit être utilisé à la place. Sur les appareils eMMC, il s’agit d’une opération Trim normale.
• Si BLKDISCARD n'est pas pris en charge, l'écrasement des périphériques de bloc avec tous des zéros est acceptable.
• Un utilisateur final doit avoir la possibilité d'exiger que les données utilisateur soient effacées avant de flasher une partition. Par exemple, sur les appareils Nexus, cela se fait via la commande fastboot oem lock .
• Un dispositif peut enregistrer, via des fusibles ou un mécanisme similaire, si un dispositif a été déverrouillé et/ou reverrouillé.

Ces exigences garantissent que toutes les données sont détruites à la fin d'une opération de déverrouillage. Le fait de ne pas mettre en œuvre ces protections est considéré comme une vulnérabilité de sécurité de niveau modéré.

Un appareil déverrouillé peut ensuite être reverrouillé à l'aide de la commande fastboot oem lock . Le verrouillage du chargeur de démarrage offre la même protection des données utilisateur avec le nouveau système d'exploitation personnalisé que celle disponible avec le système d'exploitation d'origine du fabricant de l'appareil (par exemple, les données utilisateur seront effacées si l'appareil est à nouveau déverrouillé).