sharif-dev/androidkernelvulnerabilityDéclenchement et analyse de la vulnérabilité CVE-2019-2215 du noyau Android
En novembre 2017, un bug de use-after-free dans le noyau Linux a été détecté par le système syzkaller . En février 2018, ce bug a été corrigé dans certains noyaux Linux et versions d'Android.
Ce correctif n'a jamais été inclus dans les bulletins de sécurité mensuels d'Android, il n'a donc pas été appliqué à de nombreux appareils récemment commercialisés comme les Pixel et Pixel2.
En septembre 2019, Android a été informé des implications de sécurité de ce bug par Project Zero. Android a ensuite attribué CVE-2019-2215 à cette vulnérabilité pour la rendre plus formelle et plus connue.
CVE-2019-2215 est un use-after-free dans binder.c qui permet l'élévation de privilège (obtention d'un accès root) à partir d'une application Android. Aucune interaction de l'utilisateur n'est nécessaire pour exploiter cette vulnérabilité. Elle nécessite uniquement l'installation d'une application locale malveillante.
Nous allons ici présenter cette vulnérabilité du noyau Android plus en détail et utiliser cette vulnérabilité pour obtenir un accès root (élévation de privilèges) sur l'ensemble de l'appareil Android.
Nous utiliserons cette preuve de concept (PoC) :
https://github.com/cloudfuzz/android-kernel-exploitation
Nous allons d'abord vous montrer comment déclencher cette vulnérabilité sur un émulateur Android et provoquer un crash du noyau. Ensuite, pour voir à quel point cela peut être dangereux, nous continuons en utilisant la PoC pour obtenir un accès root sur l'appareil Android simulé. Puis nous analyserons le code du noyau pour voir quelle en est la raison (analyse statique et analyse dynamique).
Après l'analyse, nous verrons comment nous avons obtenu l'accès root. Enfin, nous verrons comment cette vulnérabilité est atténuée à l'aide de correctifs.
Pour provoquer un crash du noyau en déclenchant cette vulnérabilité, nous utilisons les étapes suivantes :
Regardez la vidéo suivante :
[video]
Dans cette section (et la suivante), nous allons comprendre pourquoi le crash se produit en utilisant l'analyse statique et dynamique.
Ici, nous analyserons le code du noyau (analyse statique) pour comprendre le problème. Dans crash_report.txt se trouve le rapport de KASan qui indique qu'il s'agit d'un bug de use-after-free. Cela signifie qu'un objet est alloué dans le tas (nous en avons une référence), que nous avons ensuite libéré l'objet du tas, puis que nous l'avons appelé par erreur via une référence. Ce rapport affiche la trace de pile de ces trois étapes.
Si vous vous souvenez de ce qui précède, nous avons utilisé 'trigger.cpp' dans la PoC.
Voici le code principal de trigger.cpp:``` int main() { //1 int fd, epfd; //2 struct epoll_event event = {.events = EPOLLIN}; //3 fd = open("/dev/binder", O_RDONLY); //4 epfd = epoll_create(1000); //5 epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event); //6 ioctl(fd, BINDER_THREAD_EXIT, NULL); }
Voyons ce que fait 'trigger.cpp'.
Sous Android (comme sous les autres systèmes d'exploitation de type Unix), nous avons des processus. Chaque programme que nous exécutons crée un (ou plusieurs) processus, et ces processus sont gérés par l'OS. L'OS peut basculer entre eux (multitâche) ou terminer un processus, etc. Pour des raisons de sécurité, les processus sont isolés les uns des autres par défaut.
Dans certains cas, un processus peut avoir besoin d'échanger des données avec un autre processus. Cela s'appelle la communication interprocessus (IPC). Il existe plusieurs moyens pour les processus de communiquer sous Linux. Android a introduit un mécanisme d'IPC spécifique appelé **'Binder'**. Binder est un pilote du noyau qui facilite la communication interprocessus.
Sous Android, l'IPC peut être réalisé en appelant directement certaines méthodes du noyau (la plupart se trouvent dans drivers/binder.c) ou en utilisant des implémentations de haut niveau (par exemple en Java).
Pour utiliser **binder**, nous devons ouvrir le module binder du noyau. Cela se fait à la ligne 3 de trigger.cpp. Ensuite, nous avons un pointeur de descripteur de fichier. En utilisant ce fd, l'initiateur et les destinataires de l'IPC peuvent être identifiés dans le noyau.
Toutes les interactions avec le pilote se feront via un petit ensemble de commandes **'ioctl'** (BINDER_THREAD_EXIT, BINDER_WRITE_READ, ...).
En savoir plus sur binder : [link1](https://www.nds.ruhr-uni-bochum.de/media/attachments/files/2012/03/binder.pdf), [link2](http://rts.lab.asu.edu/web_438/project_final/CSE_598_Android_Architecture_Binder.pdf)
Sous Linux, il existe un concept appelé « **event polling** ». L'API « **epoll** » est utilisée lorsque nous voulons surveiller plusieurs descripteurs de fichier (les descripteurs de fichier sont ce que nous obtenons en ouvrant un pilote ou en travaillant avec des E/S, etc.).
**epoll** est une structure du noyau qui possède deux champs importants.
* interest list = liste des descripteurs de fichier que nous voulons surveiller.
* ready list = liste des descripteurs de fichier prêts pour les E/S.
Afin d'utiliser l'event polling, nous créons d'abord un epoll (ligne 4), puis nous ajoutons ou supprimons (EPOLL_CTL_ADD) un événement (&event) associé à un descripteur de fichier (**fd**) à notre epoll créé (**epfd**) en appelant la méthode **epoll_ctl** du noyau.
=> `epoll_event event` est un événement déclenché lorsque le fichier associé (fd) est disponible pour une opération de lecture.
Maintenant, nous comprenons ce que fait **trigger.cpp** (pas besoin d'aller plus loin !). Il ouvre le module **binder**, crée un **epoll** pour l'écouter lorsqu'il est prêt. Puis, à la ligne 6, nous sortons du binder que nous avons démarré à la ligne 3.
#### Allocation :
En appelant open(), nous appelons en réalité **open_binder()** (l'implémentation de open() dans binder.c). Dans open_binder(), une nouvelle structure **'binder_proc'** sera créée et :
` fd->pricate_data = binder_proc`
En appelant **epoll_create(),** une nouvelle structure epoll sera créée et ajoutée à une structure de file d'attente.
