Dans le dernier article du blog Project Zero, l'équipe a découvert un moyen de contourner la protection du noyau en temps réel de Samsung, appelé Knox Hypervisor.
L'équipe Project Zero de Google a vérifié un certain nombre d'exploits qui permettent d'attaquer les téléphones Samsung exécutant la suite de sécurité Samsung Knox, soi-disant sécurisée. Le blog note que toutes les vulnérabilités ont été transmises à Samsung, qui a publié des correctifs dans une mise à jour logicielle de janvier.
Arrière-plan
Dans le cadre de la suite logicielle de sécurité Samsung Knox introduite par Samsung, il existe un logiciel situé entre les applications Android et le noyau appelé Hyperviseur. Cela peut être utilisé comme couche supplémentaire pour sécuriser davantage les appareils Android. L'hyperviseur Samsung Knox s'appelle "Protection du noyau en temps réel" ou RKP en abrégé, comme j'y ferai référence dans la suite de cet article.
Le noyau se trouve en dessous de RKP dans la pile logicielle Android, et les applications qui s'exécutent sur l'appareil se trouvent en haut. L'idée derrière RKP est de fournir une couche de sécurité supplémentaire pour l'appareil car toutes les demandes (mémoire et autres ressources) effectuées par les applications vers le noyau doivent d'abord passer par Knox, qui tente de détecter si une application fait quelque chose. je ne devrais pas. RKP assure également la sécurité dans l'obscurité avec une couche supplémentaire permettant de masquer les informations sensibles qu'une application pourrait utiliser pour compromettre l'appareil.
L'article de blog approfondit le fonctionnement de la mémoire Android, du RKP et des systèmes d'exploitation en général. Je l'ai donc condensé et simplifié pour donner un aperçu rapide de ce qui a été découvert. Je vous encourage cependant à lire l’article complet si vous avez le temps, car il est très instructif.
Exploite n°1 :
KASLR ou Kernel Address Space Layout Randomization est le processus de modification de l'emplacement du code du noyau en mémoire d'une quantité aléatoire au démarrage. Chaque fois que le périphérique est démarré, le noyau est chargé dans un espace d'adressage différent (zone de mémoire). L'idée est de rendre plus difficile la recherche de l'emplacement du code du noyau afin de l'attaquer car après chaque démarrage, le code du noyau se "décale" d'une quantité aléatoire dans la mémoire. Cela semble être une mesure importante pour empêcher les attaquants potentiels, mais récemment recherche a montré que vous pouvez réellement vaincre ce problème sans nécessiter de bug logiciel ou de vulnérabilité, car KASLR est en réalité très difficile à mettre en œuvre de manière robuste contre les attaquants locaux.
Dans le cas du logiciel RKP, la possibilité de contourner KASLR est en réalité plus simple que la recherche référencée ci-dessus. La mémoire de tous les appareils Android est référencée par des pointeurs et afin de protéger les appareils contre les attaques, chaque fois que les appareils Android impriment ou sortent (que ce soit pour écran ou à classer pour les journaux ou le débogage), les références des pointeurs sont anonymisées, ce qui rend impossible de savoir où pointe réellement le pointeur lors de la lecture du sortir.
Pensez aux pointeurs de mémoire comme un panneau de signalisation qui pointe vers un emplacement et pensez à l'anonymisation comme à un brouillage de cet endroit. Tout comme à la télévision, l'anonymisation se fait après le tournage, Android applique également cette anonymisation au moment de la sortie et seulement si l'anonymisation est correctement configurée, et l'auteur précise que chaque appareil [qu'il] a rencontré a eu l'anonymisation du pointeur correctement configurée. Cela peut sembler très difficile à briser, mais tout ce que vous avez à faire est de trouver un seul pointeur (pensez à un panneau de signalisation) qui n'a pas été anonymisé (flou). par le développeur du noyau (attention, il ne s'agit pas d'un développeur d'applications Android moyen) lorsque le pointeur est écrit dans les journaux ou à un autre emplacement, par exemple. écran ou un déposer.
Ainsi, si vous pouvez trouver un pointeur qui n'a pas été anonymisé, vous pouvez alors calculer le décalage d'adresse aléatoire du noyau comme la différence entre les deux. Il est intéressant de noter que l'auteur n'a pas pu trouver de pointeur exploitable dans le noyau, mais l'a trouvé dans le RPK. où les développeurs ont oublié d'anonymiser un pointeur dans la sortie de débogage (journalisation), ce qui s'est produit via un faute de frappe. Pour anonymiser les pointeurs dans Android, vous devez utiliser un code spécial et il s'avère que les développeurs RPK ont utilisé par erreur un « k » minuscule au lieu d'un « K » majuscule. Il était donc relativement simple de déterminer la quantité de décalage aléatoire du code du noyau et de l'attaquer.
Exploite n°2 :
L'exploit suivant est un peu plus complexe: Samsung Knox protège votre appareil en appliquant un ensemble de règles à la mémoire de l'appareil pour arrêter le code malveillant. Les règles sont les suivantes:
- Toutes les pages (code en mémoire), à l'exception du code du noyau, sont marquées comme "Privileged Execute Never" (ce qui signifie que le code ici ne peut jamais s'exécuter)
- Les pages de données du noyau (données utilisées par le programme en mémoire) ne sont jamais marquées comme exécutables (le code ici ne peut donc jamais s'exécuter)
- Les pages de codes du noyau (code en mémoire) ne sont jamais marquées comme étant accessibles en écriture (donc aucun code malveillant ne peut le modifier)
- Toutes les pages du noyau sont marquées en lecture seule dans la table de traduction de l'étape 2 (la table qui se situe entre l'application et le noyau pour empêcher davantage les applications de connaître les emplacements de mémoire réels)
- Toutes les entrées de traduction de mémoire sont marquées comme en lecture seule pour les applications.
Nous nous concentrerons sur la règle 3 car c'est là que l'auteur a trouvé un problème avec la mise en œuvre des règles ci-dessus. RPK marque en fait la mémoire du noyau comme étant en lecture seule, mais par oubli du KASL, un trou a été découvert, ce qui a conduit à écrire du code dans la section soi-disant "en lecture seule". Afin de masquer l'emplacement du noyau au démarrage, de la mémoire est allouée au noyau, mais cette quantité de mémoire est beaucoup plus grande que le segment de texte du noyau. En allouant une plus grande quantité de mémoire, il est beaucoup plus difficile de trouver le code réel du noyau qui pourrait se trouver n'importe où, et comme nous l'avons vu ci-dessus, il est déplacé de manière aléatoire à chaque démarrage du périphérique.
L'auteur a pu confirmer que la mémoire utilisée par le noyau était bien marquée en "lecture seule", cependant le reste de cette grande quantité de mémoire utilisée pour cacher le noyau était pas marqué comme "lecture seule". En effet, RKP ne protège que la région contenant le texte du noyau après avoir appliqué la diapositive KASLR.
Exploite n°3
Dans le troisième exploit, l'auteur a pu accéder à une autre zone de mémoire qui devrait également être limitée en lecture seule. Le RKP protège la mémoire et utilise un Registre de configuration de l'hyperviseur (HCR) pour contrôler les opérations clés du noyau. Le but du HCR est de permettre aux opérations valides et réelles du noyau d'accéder aux registres et de bloquer les attaques malveillantes. Pour ce faire, il vérifie les appels effectués aux registres qui régissent les fonctionnalités de virtualisation. Le HCR est configuré pour bloquer des opérations spécifiques qui seraient traitées normalement, permettant à RKP de choisir d'autoriser ou de refuser une demande.
Dans cet exploit, le contrôle HCR était ne couvrant pas deux registres cela s’est avéré très important. L'auteur a fouillé en profondeur dans le manuel de référence ARM et a découvert que le premier registre lui permettait essentiellement de désactiver RKP pour les applications. Le "Le registre de contrôle système pour EL1 (SCTLR_EL1) fournit un contrôle de niveau supérieur sur le système, y compris le système de mémoire.. " Dans un monde parfait, l'application utiliserait la mémoire mappée via le RKP afin que le RKP puisse contrôler ce à quoi l'application peut accéder. Cependant, la désactivation de ce registre a permis au RKP sera désactivé en ramenant efficacement l'appareil à la façon dont il fonctionnait avant l'installation de RKP, ce qui signifie que l'appareil est mappé à la mémoire physique sans la sécurité supplémentaire fournie par RKP. Cela signifiait à son tour que l'auteur pouvait lire et écrire dans la mémoire qui était à l'origine et correctement bloquée par le logiciel RKP.
Le deuxième registre manqué a eu un effet plus subtil, mais finalement tout aussi dévastateur pour la sécurité. Le Registre de contrôle de traduction pour EL1 Le registre (TCR_EL1) est directement lié à la quantité de mémoire avec laquelle une application fonctionne appelée page. RKP est codé en dur sur une taille de page de 4 Ko car les noyaux Linux AARCH64 (tels qu'Android) utilisent une taille de traduction de 4 Ko. Le registre en question (TCR_EL1) définit les chipsets ARM sur la taille de mémoire à restituer. Il se trouve que ce registre n'est pas protégé par le HCR et donc un attaquant peut le modifier car l'auteur l'a modifié en une taille de page de 64 Ko.
Cela signifie que lorsque la demande est satisfaite par RKP, la quantité réelle de mémoire accessible est désormais de 64 Ko au lieu de 4 Ko. La raison en est que le chipset ARM contrôle toujours la taille de la page et qu'elle a été fixée à 64 Ko par l'exploit. Puisque le RKP protège la mémoire contre l'écriture, dans le cadre des règles répertoriées dans l'exploit n°2, la mémoire est toujours réellement protégée. Mais voici le problème: puisque RKP est codé en dur à 4 Ko, il ne passe pas à une taille de page de 64 Ko lorsque le registre a été mis à jour, donc seuls les 4 premiers Ko de mémoire sont protégés permettre à l'attaquant de faire ce qu'il veut avec les 60 Ko restants.
Exploite n°4
Le dernier exploit présenté par l'auteur fait référence à la mémoire où se trouve le logiciel RKP, afin que l'attaquant puisse attaquer le logiciel RKP lui-même. Une astuce pour arrêter ce type d'attaque que les noyaux Linux utilisent également consiste à démapper votre programme de l'espace d'adressage de la mémoire virtuelle afin qu'aucune application ne puisse l'attaquer car elle ne peut pas le référencer.
N'oubliez pas que la mémoire est constituée de pointeurs et de tables qui mappent la mémoire physique à la mémoire virtuelle. Conformément à la défense normale dans ce type d'attaque, RKP se décarte afin qu'il ne puisse pas être attaqué. Cependant, là où le noyau ne fournit pas de telles capacités, RKP permet de mapper et de marquer une partie de la mémoire en lecture/écriture. La seule vérification est qu'il ne s'agit pas du noyau sous-jacent lui-même, car RKP ne vérifie pas si les adresses dont le mappage est demandé correspondent à la zone où RKP lui-même réside en mémoire. En gros, RKP se laisse re-cartographier dans l'espace d'adressage auquel les applications peuvent accéder et, en tant que côté, affecter le la mémoire est automatiquement marquée comme lecture/écriture un attaquant peut donc désormais utiliser la mémoire comme il le souhaite.
Conclusion
L'un des plus gros problèmes avec les quatre exploits répertoriés ci-dessus est que l'auteur mentionne à quel point ils seraient difficiles à réaliser en raison du manque de fonctions dans le noyau Android de base. Ironiquement, l'hyperviseur sécurisé RKP a fourni tous les outils nécessaires pour mener à bien les attaques. Cela montre que parfois des logiciels bien intentionnés causent plus de problèmes qu'ils n'en résolvent et nous avons de la chance d'avoir des gens comme Gal Beniamini prêt à mettre la main à la pâte et à tester que la documentation correspond à ce que le logiciel contient réellement fait.
Bien que ces exploits semblent effrayants et donnent l'impression que Knox est très vulnérable, je voudrais rassurer tout le monde sur le fait que ces problèmes ont tous été résolus. corrigé dans la mise à jour de janvier de Samsung. De plus, ces exploits nécessitent une compréhension très approfondie des processeurs et de la programmation ARM, de sorte que la barrière à l’entrée dans l’utilisation de ces exploits est astronomiquement élevée.
Source: Projet Zéro