Activité de GrapheneOS sur les réseaux sociaux
- GrapheneOS fait partie d’un réseau social fédéré basé sur Mastodon.
- Le projet exploite un serveur GrapheneOS pour le compte officiel du projet et ses membres.
- Le serveur compte 5 utilisateurs actifs.
Prise en charge du marquage mémoire matériel sur les Pixel 8 et Pixel 8 Pro
- Grâce à la prise en charge du marquage mémoire matériel sur les Pixel 8 et Pixel 8 Pro, GrapheneOS a découvert un bug de corruption mémoire dans Bluetooth LE d’Android 14 QPR2.
- Le projet étudie actuellement ce bug afin de le corriger ou de trouver une solution de contournement temporaire consistant à désactiver provisoirement la fonctionnalité nouvellement introduite.
Désactiver le marquage mémoire n’est pas une solution temporaire appropriée
- Le problème ne se produit qu’avec certains appareils Bluetooth LE, et pas avec tous les appareils Bluetooth.
- Désactiver le marquage mémoire pour ce processus n’est pas acceptable, même comme solution à court terme.
Développement d’un correctif pour le bug d’Android 14 QPR2
- Un bug de type use-after-free lié à Bluetooth LE a été découvert et un correctif a été développé.
- La priorité est d’inclure le correctif dans une version de GrapheneOS, puis de le signaler comme bug de sécurité Android.
- Il devrait aussi résoudre les problèmes d’audio BLE.
Vérification de la correction du bug
- Un utilisateur disposant de Samsung Galaxy Buds2 Pro a reproduit le problème en mode Bluetooth LE et a confirmé l’efficacité du correctif.
- Le problème affecte également l’OS Pixel par défaut.
- GrapheneOS l’a détecté grâce à la prise en charge du marquage mémoire dans hardened_malloc et a ajouté une fonction permettant d’envoyer des alertes et des rapports de crash MTE.
Signalement comme bug de sécurité
- Le problème de use-after-free a été signalé comme bug de sécurité (b/328916844 pour les employés de Google).
- Un correctif initial à intrusion minimale a été fourni.
- Le code a besoin d’un important refactoring et ne devrait pas utiliser de pointeurs bruts, mais l’objectif est d’éviter d’introduire de nouveaux bugs avec un correctif rapide.
Portage du code Bluetooth vers Rust
- Android a porté une grande partie du code Bluetooth vers Rust.
- Davantage de ressources devraient être consacrées au portage du reste du code vers Rust.
- Les builds HWASan et MTE doivent être testés dans divers environnements d’usage réel.
Importance de MTE
- Les Pixel disposent de MTE, une importante fonctionnalité de sécurité matérielle, qui n’est pas activée par l’OS afin d’économiser 3,125 % d’utilisation mémoire/cache.
- GrapheneOS active MTE par défaut pour l’OS de base et pour les applications utilisateur installées connues comme compatibles.
- Les utilisateurs peuvent activer MTE pour toutes les applications utilisateur installées dans les paramètres.
Implémentation de MTE dans GrapheneOS
- GrapheneOS fournit une meilleure implémentation de MTE dans le cadre de hardened_malloc, avec des tags aléatoires standard et un tag dédié pour les blocs libérés.
- Le projet a corrigé l’intégration de Chromium et prévoit d’améliorer PartitionAlloc.
Utilisation de MTE par GrapheneOS
- GrapheneOS est la première plateforme à utiliser MTE en production.
- Le navigateur Vanadium est le premier navigateur à utiliser MTE en production.
- Le projet prévoit d’ajouter le stack MTE, d’améliorer PartitionAlloc et de créer un nouveau kernel slab MTE.
Remerciements des utilisateurs
- Des utilisateurs ont exprimé leur gratitude pour la fonction de désactivation automatique du Bluetooth de GrapheneOS.
L’avis de GN⁺
- GrapheneOS est un système d’exploitation axé sur la sécurité, basé sur Android, qui a montré sa capacité à découvrir rapidement et à traiter un bug de corruption mémoire trouvé sur les derniers appareils Pixel.
- Cette réactivité illustre bien les avantages de la communauté open source et contribue à offrir aux utilisateurs un environnement mobile plus sûr.
- Le portage du code vers Rust, un langage qui renforce la sûreté mémoire, constitue une étape importante pour améliorer la sécurité à long terme.
- Activer MTE, une fonctionnalité de sécurité matérielle, est un moyen efficace de renforcer la sécurité tout en minimisant l’impact sur les performances.
- Lors de l’adoption de cette technologie, il faut prendre en compte la compatibilité avec les applications existantes et prévoir des tests ainsi qu’une maintenance adaptés au renforcement de la sécurité.
1 commentaires
Avis Hacker News
L’extension de marquage mémoire n’est pas activée par défaut, mais n’importe qui peut l’activer via les options développeur. On peut l’activer une seule fois pour tester une application spécifique, ou la laisser active aussi longtemps qu’on le souhaite.
Attente d’une réponse d’utilisateurs de GrapheneOS sur la difficulté d’installation de GrapheneOS, la nécessité éventuelle d’un câble spécial, le besoin de bien connaître les appareils Android, ou s’il suffit simplement de suivre les instructions.
Demande de retours d’expérience pour savoir si l’usage quotidien de GrapheneOS est contraignant, si le téléphone plante souvent au point de nécessiter plusieurs jours de débogage, et si les applications bancaires fonctionnent.
Interrogation sur la manière dont l’équipe Pixel justifie la décision de ne pas activer dans l’OS une fonctionnalité matérielle de sécurité importante (MTE) afin d’économiser 3,125 % d’utilisation mémoire/cache. Le heap MTE n’a pratiquement aucun surcoût de performance en mode asynchrone, et en mode asymétrique il coûte moins cher que des protections existantes comme SSP, dont l’efficacité diminue progressivement.
Question sur la comparaison entre les technologies de sécurité MTE et CHERI.
GrapheneOS est tellement en avance sur le plan de la sécurité par rapport aux autres options que le choix d’un matériel autre que Pixel paraît discutable. Mais fort désir d’avoir une batterie remplaçable.
Question sur le fait de savoir si des ordinateurs monocartes comme les Raspberry Pi récents implémentent Arm MTE.
Attente d’un matériel grand public capable de résoudre les problèmes de corruption mémoire, à l’image du matériel Solaris SPARC de 2015 ou d’architectures antérieures à mémoire étiquetée. Ces problèmes sont le plus souvent causés par des développeurs peu compétents.
En 2024, il faut des systèmes d’exploitation, applications et outils qui reprennent l’esprit de seL4, mais avec une vérification formelle encore plus stricte. Continuer à utiliser, comme aujourd’hui, des systèmes fondés sur des bases de code insuffisamment testées et excessivement conçues fait courir des risques aux utilisateurs et offre une vaste surface d’attaque aux bugs, malwares et piratages.
Sans une expérience utilisateur (UX) propre et intégrée ainsi que des fonctionnalités réellement utilisables, tout ce travail d’ingénierie est vain.
Android a porté une partie importante du code Bluetooth en Rust. C’est un exemple qui montre qu’il faudrait consacrer davantage de ressources au portage de plus de code vers Rust.
Une personne ayant des années d’expérience en C et C++, mais aucune en Rust, se demande combien de refactoring est nécessaire lors d’un portage de C vers Rust. Question aussi sur l’approche de Google : essaie-t-il de faire une « traduction » aussi directe que possible, ou considère-t-il cela comme une occasion de réécriture/refactoring majeur ?
Curiosité quant à savoir si la pile Bluetooth d’Android peut être utilisée sur des systèmes de bureau de distributions Linux standard.