Ce 21 août dernier vous avez certainement entendu parler de la dernière éclipse solaire en date, mais si vous n’étiez pas aux États-Unis ou sur la pointe Bretonne à ce moment-là, vous n’avez surement pas réellement pu en profiter. Néanmoins un autre évènement a eu lieu ce jour-là, un moins dangereux qui ne nécessitait pas d’appliquer de la crème solaire dans les yeux. C’était la sortie officielle de la version 8 d’Android : Android Oreo.

Cette nouvelle release apporte comme à chaque fois son lot de nouveautés. Certaines seront visibles ou devraient se faire ressentir rapidement. Comme par exemple : les améliorations sur la gestion de la consommation de la batterie des applications qui fonctionne en arrière-plan, les optimisations apportées sur le temps de redémarrage et de lancement des applications (mesurées sur les smartphones de la gamme Pixel), ou encore la fonction « Autofill » qui est plus ou moins un équivalent du « trousseau » sur les plateformes d’Apple. Cette version embarque bien plus de nouveautés encore qui seront appréciables à l’utilisation (sélection de textes plus intelligente, système de notification revu, « picture in picture », nouveaux émojis…) mais à l’instar de l’éclipse solaire ou d’un double Oreo, c’est surtout dans l’ombre que cette nouvelle version pourrait briller. En effet, à tort ou à raison, les deux critiques majeures de l’OS de Google qui reviennent le plus souvent sont : le taux d’adoption des dernières versions et la sécurité de celui-ci, deux problèmes que Google souhaite adresser avec Oreo. Le premier point avec le projet Treble permettant d’extraire et d’abstraire du framework d’Android, les APIs de bas niveaux spécifiques à chaque appareils et composants. Cela devrait rendre les mises-à-jour pour les différents constructeurs de téléphones Android plus facile et permettre à ces derniers de faire un meilleur suivi des versions Android dans le temps. Le deuxième point est composé de différentes stratégies qui seront abordées dans la suite de cet article. – Analyse par Florent BENNANI – Consultant chez Agile Partner

Carte d’identité

Nom : Android Oreo

Genre : Système d’exploitation mobile

Créateur : Android Inc racheté par Google en 2005 | Open Handset Alliance (OHA)

Particularité : Système d’exploitation Installé sur plus de 2 milliards d’appareils actifs.

Sécuriser ses Oreos en bref

L’équipe d’Android n’en est pas à ses débuts dans le domaine de la sécurisation de son OS. Avec chaque nouvelle release vient une nouvelle itération pour améliorer la sécurité de l’écosystème. Avec Android Nougat, la version 7 de son système d’exploitation, les équipes de Google s’étaient concentrées sur une isolation plus net du kernel par rapport au userspace en y ajoutant notamment des filtres sur le contrôle des entrées/sorties (ioctl filtering) via l’intégration de SELinux, ou en empêchant le kernel d’accéder directement aux espaces mémoires du userspace. L’idée étant d’une part de réduire la surface potentielle d’attaque en limitant ou en supprimant l’accès de certains modules du système qui n’ont pas besoin d’être exposés, et d’autre part en diminuant les accès directs du kernel au userspace.

Très grossièrement, le userspace est un espace en mémoire où des processus (comme des applications par exemple) sont stockés et exécutés quand ils sont lancés. Cet espace mémoire est celui qui a le moins de privilèges car n’importe quel programme peut s’exécuter. Le userspace ne peut (en théorie) en aucun cas accéder directement au kernel space, mais peut néanmoins communiquer avec ce dernier via ce qu’on nomme des « appels systèmes ». Le kernel, qui est le noyau d’un système d’exploitation, fonctionne comme un contrôleur ou un orchestrateur pour ce dernier, entre les ressources de l’appareil et les différents processus qui sont exécutés dans celui-ci. Il peut lui, a contrario, accéder à tout l’espace mémoire d’un appareil ainsi qu’à ses composants, et dispose de tous les privilèges. L’une des différences entre ces deux espaces est que chaque processus qui s’exécutent dans le userspace est séparé des autres, alors que le kernel n’est qu’un seul grand espace mémoire. Cela veut dire que si un attaquant arrive à corrompre un espace mémoire du userspace, il ne peut accéder qu’à cet espace, mais s’il arrive à se frayer un chemin dans le kernel space, il peut accéder à tout l’appareil.

C’est pourquoi après avoir isolé le kernel du reste du système, les équipes de Google se sont intéressées à renforcer le kernel lui-même dans la huitième version d’Android. Pour cela ils ont pris quatre angles d’attaques.

Hardened usercopy functions

Depuis la version 4.8 du kernel linux, les « usercopy functions » (copy_from_user() / copy_to_user(), et autres) ont été amélioré et surtout renforcé en y ajoutant des vérifications supplémentaires. En effet ces fonctions servent à envoyer des données entre le kernel et le userspace et vice versa. Jusque-là, il arrivait souvent que des vérifications d’accès mémoire soient mal, voire pas exécutées, ce qui pouvait entrainer des erreurs plus ou moins sévères, voire des vulnérabilités au niveau kernel (45% des vulnérabilités depuis 2014 sur les système Android sont causés suite à des problèmes de vérifications). Grâce à cela les vérifications de l’intégrité des données transmises entre le kernel et le userspace seront automatisées, comme par exemple, de savoir si le kernel ne va pas copier plus de données qu’attendu depuis le userspace, ce qui pourrait résulter à l’écrasement d’une partie de la mémoire du kernel par du code malicieux ; ou inversement à écrire trop de chose vers le userspace et faire fuiter du contenu de la mémoire du kernel qui pourrait contenir des données critiques. Par ailleurs, le renforcement de ces fonctions permet aussi de prévenir l’exploitation de bugs se trouvant dans des drivers qui s’avèrent souvent être une porte d’entrée de choix pour un attaquant et accéder au kernel (85% des failles kernel d’Android proviennent de drivers de constructeurs externes).

Les équipes d’Android ont donc décidés de reporter ces améliorations à partir de la version 3.18 du kernel linux et supérieur, ce qui correspond à la version 6.0 (Marshmallow) et plus.

Privilège Access Never (PAN) emulation

Renforcer les fonctions de copie de données entre le kernel et le userspace est une bonne chose, néanmoins il reste encore un problème majeur, les développeurs ne les utilisent pas forcément. Jusque-là, tout le code contenu dans le kernel d’Android pouvait potentiellement accéder au userspace sans réel restriction et sans passer obligatoirement par ces fonctions de copie. Cela inclus aussi la majorité des drivers embarqués par le système, ce qui, comme exposé précédemment, peut entrainer de gros soucis de sécurité.

Pour pallier à ce problème, les constructeurs de CPU ont mis en place des systèmes pour prévenir et empêcher ce genre d’accès directe à la mémoire depuis le kernel vers le userspace. Et ainsi forcer les développeurs à utiliser les « usercopy functions ». En effet des techniques comme le SMAP (Supervisor Mode Access Prevention) ou le PAN (Privileged Access Never) ont été introduit respectivement dans les CPUs de type x86 (Intel), et ARM v8.1 et empêchent au kernel tout accès au userspace sauf quand explicitement demandé notamment par le biais de ces fonctions. Néanmoins très peu de terminaux Android sont équipés de ce genre de processeurs. Cependant, depuis quelques versions (4.3 pour la version ARM et 4.10 pour la version ARM64), le kernel linux a intégré une émulation logicielle du PAN et là encore, les équipes d’Android ont décidé de reporter ces fonctionnalités à partir de la version 3.18 du kernel Linux.

Kernel Address Space Layout Randomization (KASLR)

Bien que son efficacité soit encore discutée aujourd’hui, le KASLR est une technique permettant de prévenir ou de rendre plus difficile certains types d’attaques (type « code reuse attacks » par exemple) en rendant hasardeux l’endroit où le kernel est chargé en mémoire à chaque redémarrage du système. KASLR est disponible sur le kernel linux pour les CPU de type ARM64 depuis la version 4.6 et une fois de plus les équipes de Google ont rendu disponible cette fonctionnalité à partir de la version 4.4 du kernel Linux (version 7.0-7.1 Android Nougat).

Post-init read-only memory

Enfin, la dernière fonctionnalité majeure en termes de sécurité ajoutée à cette nouvelle version d’Android consiste à bloquer des pans de mémoires en lecture seule une fois que le système a fini de s’initialiser. En effet, il est plus difficile d’exploiter des failles si elle se trouve dans un espace mémoire où seule la lecture est possible. Cela permet aussi de protéger ces espaces pour qu’ils ne puissent pas être écrasés par un bout de code malicieux. Android offre donc ainsi la possibilité aux développeurs d’avoir plus de contrôle sur les données qui ont besoin d’un accès en écriture pendant la phase d’initialisation mais qui ne doivent plus changer par la suite.

Une fois de plus cette fonctionnalité est disponible depuis la version 4.6 du kernel linux et a été portée sur les version 3.18 et supérieures.

On vous le dit !

Avec cette nouvelle version Google veut continuer à renforcer son système d’exploitation. Néanmoins, comme l’explique Adrian Ludwig directeur de la sécurité d’Android dans une interview accordé à wired, le domaine de la sécurité ne demeure pas dans l’immédiateté. Parfois certains changements réalisés il y a plusieurs années ne deviennent qu’utile aujourd’hui et certaines décisions prisent aujourd’hui n’auront de réels impacts que dans quelques années. C’est plus souvent un jonglage entre réactivité et anticipation qui permet une bonne stratégie de sécurité.

Cependant, les équipes de Google ne naviguent ni à vue ni au hasard. Fort d’outils intégrés depuis plusieurs années sous différents noms, comme le Google Play Protect par exemple, offrant la capacité de scanner plus de 50 milliards d’applications par jour, leur permet de savoir vers quelle direction s’orienter, et d’agir toujours plus vite quand le besoin s’en fait ressentir. Grâce à cela, ils arrivent à stopper et corriger des failles alors même qu’une centaine d’utilisateurs seulement sont impactés par un nouveau malware, ce qui leur permet aussi de voir les tendances des nouvelles menaces et planifier les réponses appropriées pour les prochaines versions.

Sources :

• https://www.androidpit.com/android-oreo-release-features-news
• https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html
• https://android-developers.googleblog.com/2016/07/protecting-android-with-more-linux.html
• http://www.linfo.org/user_mode.html
• https://www.wired.com/story/android-oreo-security-improvements/