Cette semaine en sécurité : GTA, Apple et Android, et démarrage non sécurisé

Lorsque nous avons vu pour la première fois des tweets sur un problème de sécurité dans Grand Theft Auto V, cela ressemblait un peu à un troll. « Appuyez sur ‘alt et f4’ pour déverrouiller un mode de triche », ou le pirate qui prétend pouvoir supprimer votre personnage. [Tez2]le tweet d’avertissement de que vous ne devriez pas jouer à GTA Online sans pare-feu ressemble à une autre de ces légendes urbaines en ligne. Mais celui-ci semble en fait légitime. Le NIST est même de la partie, attribuant CVE-2023-24059 à l’exploit.

Lorsqu’ils jouent à un jeu en ligne, d’autres utilisateurs envoient une « demande d’adhésion » pour rejoindre la session active. Ces paquets peuvent contenir des données mal formées qui ont fait planter le client du jeu à distance. On pense, bien que cela ne soit pas confirmé publiquement, qu’il s’agit également d’une vulnérabilité d’exécution de code à distance (RCE). Il semble probable que cet aspect sera ajouté à certains des différents panneaux de triche déjà largement utilisés pour ce jeu vieux de 10 ans. Alors maintenant, plutôt que de simplement donner à votre propre personnage des munitions et une santé infinies, vous pouvez infliger des ravages aux autres joueurs, pouvant aller jusqu’à corrompre leurs fichiers de personnage et les faire bannir.

Mais pourquoi s’arrêter là ? Si nous avons l’exécution de code dans le jeu, qu’est-ce qui empêche un autre joueur de lancer une véritable attaque ? Un jeu vidéo n’est pas en bac à sable comme un navigateur, et rien n’empêche une attaque d’effaceur de disque ou même un ver de compromettre un groupe de joueurs. Le pire, c’est que c’est un vieux jeu, et même s’il y a une grande base de joueurs, il n’est pas garanti d’obtenir une solution. Il y a au moins un projet visant à être un pare-feu pour éviter le problème.

Les bogues de 19 et 20 ans de XNU

[Adam Doupé] semble avoir le don de trouver d’anciens bogues dans le code d’Apple, et cette fois, il s’agit d’une paire de défauts très anciens dans le noyau d’Apple, XNU. Le premier est un problème de dlil.c, le gestionnaire d’interface réseau. Ce problème est une erreur de conversion de type, où un int est converti en uint_16. Si ce cast déborde, la valeur devient un grand nombre négatif et l’écriture de données suivante dépasse le tampon et écrit hors limites. La méthode pour déclencher celle-ci est un peu délicate, car elle nécessite la création de 65536 interfaces réseau.

Il existe deux approches pour déclencher cette condition. Le premier est le plus simple, un petit script s’exécutant en tant que root, qui appelle ifconfig à plusieurs reprises pour créer les interfaces. Bien que cela puisse être intéressant dans le cadre d’une chaîne d’exploitation, l’idée la plus intéressante est de créer un dongle USB malveillant qui se présente comme plusieurs interfaces réseau. Le reste du message est [Adam]de transformer l’underflow en exploit. Il n’a pas tout à fait réussi, mais il semble que ce soit possible.

Le deuxième bogue est encore plus ancien, une faille de 20 ans dans XNU ndrv.c, le gestionnaire de socket brut. C’est un cas limite où une liste chaînée avec deux membres est mal parcourue, l’un des membres de la liste est libéré, mais l’élément parent contient toujours un pointeur vers la mémoire maintenant libérée. Les deux bogues ont maintenant été corrigés dans les dernières versions d’iOS et de macOS.

Android (ARM) aussi

Android n’est pas du genre à être laissé de côté, avec une excellente rédaction de [Man Yue Mo] de Github Security Lab, à propos d’un problème dans le GPU Arm Mali fourni avec les appareils Pixel 6. Avec une grande ironie, on nous raconte comment le seul élément non Google dans le téléphone entièrement Google a conduit à l’exploitation de l’espace du noyau à partir d’une application. Plus précisément, il s’agit du pilote de ce GPU et de la manière dont il gère la mémoire JIT, c’est-à-dire des segments de mémoire gérés par le noyau et accessibles par l’espace utilisateur et directement par le GPU. Et comme vous vous en doutez, avoir trois composants différents accédant à la mémoire en même temps peut causer des problèmes.

Dans ce cas, le problème est de savoir comment l’expulsion est gérée. Ces morceaux de mémoire sont traités, puis peuvent être renvoyés au magasin gratuit. Une optimisation des performances par le pilote consiste à garder les mémoires tampons « chaudes », sans demander au noyau de les libérer et en sautant le processus d’allocation lorsque la prochaine requête est nécessaire. Le problème est que la mémoire dans cet état de limbes est considérée comme « expulsable », et le noyau peut libérer ces régions sans le faire via le pilote GPU. Cela laisse le système dans un état étrange où le pilote GPU et l’espace utilisateur ont toujours des pointeurs valides vers un emplacement mémoire, mais le noyau l’a marqué comme libre. Le vrai plaisir commence lorsque l’emplacement de mémoire libéré est revendiqué par un processus d’attaque et qu’un faux objet JIT est mis à sa place. Par une manipulation intelligente de la mémoire, cela peut être exploité pour produire un mappage de l’espace utilisateur du code du noyau, qui peut ensuite être lu et écrit. Et l’étape la plus simple à partir de là consiste simplement à modifier l’application de l’espace utilisateur, en la faisant fonctionner en tant que root.

C’est une trouvaille intelligente, mais ce qui ressort vraiment, c’est le problème de le faire réparer. Cela a été signalé aux ingénieurs d’Android en juillet 2022, et quelques semaines plus tard, le rapport a été clôturé en tant que problème « Ne résoudra pas ». Il y a un point légitime ici, que ce n’est pas le code Android qui contient le problème, et cela devait être corrigé dans le pilote ARM. ARM a publié une mise à jour qui a résolu le problème moins de trois mois plus tard, en août 2022. Une divulgation coordonnée était prévue avec ARM pour novembre, mais il semble que les ingénieurs Android aient complètement abandonné le bogue et ont attendu la mise à jour de janvier pour enfin expédier le correctif aux utilisateurs d’Android. Et quand il est finalement arrivé, il a été suivi comme un bogue complètement différent, ce qui signifie que le rapport d’origine a été fermé et oublié. C’est un peu décourageant de voir Google montrer une attitude aussi désinvolte envers une vulnérabilité de cette gravité, sur son propre produit.

Encore une fois

Cela commence à ressembler à une mauvaise idée de mettre le pilote Server Message Block Daemon dans le noyau Linux, car nous avons un autre sous-dépassement d’entier de pré-autorisation conduisant à un déni de service. Les chercheurs de Sysdig ont trouvé la faille cette fois, en recherchant sur la base du précédent ZDI-22-1690, qui était un RCE plus sérieux dans le même module de noyau. Celui-ci est un peu différent des autres débordements entiers que nous avons examinés. La nature enveloppante des entiers évite à cette vulnérabilité d’être plus grave.

Le vrai problème est que lors de l’authentification SMB, la structure de données de l’utilisateur distant contient une paire de valeurs de longueur, qui sont utilisées pour analyser les données d’authentification entrantes. Il est évident que ces valeurs ne sont pas implicitement fiables, et une bonne vérification des erreurs est effectuée pour éviter un débordement de tampon trivial. Le cas qui nous fait trébucher, c’est quand nt_len est inférieur à CIFS_ENCPWD_SIZE, et la valeur résultante est négative. Lorsque cet entier négatif est converti en non signé size_t dans un memcpy() appel, l’entier négatif est « déballé » à une valeur presque maximale size_t. La fonction de copie de mémoire tentera l’instruction, mais il s’agit d’une opération plutôt incontrôlée, et finit par atteindre une mémoire inaccessible et panique le noyau. Jusqu’à présent, il ne semble pas y avoir de moyen de transformer ce défaut particulier en un véritable RCE. Et d’ailleurs, après toutes ces années, tout le monde sait sûrement qu’il ne faut pas exposer un service SMB à des utilisateurs non fiables, n’est-ce pas ?

Démarrage non sécurisé

Bien que Secure Boot ne se soit pas tout à fait avéré être le verrouillage dystopique du PC que certains d’entre nous craignaient, il est parfois difficile de gérer tout en essayant de réparer quelque chose sur une machine en panne. Besoin d’un disque de démarrage personnalisé pour exécuter un outil ? Oui, il est temps de désactiver le démarrage sécurisé. Mais il y a quelques cas où cela est utile, comme empêcher les logiciels malveillants de démarrage de s’implanter dans un système crypté. Il y a peut-être quelque chose à dire pour une quantité connue comme le démarrage sécurisé.

C’est pourquoi il est un peu étrange de constater que MSI a décidé de le compromettre en masse sur ses cartes mères de bureau dans une mise à jour du firmware publiée en janvier dernier. Et notez que MSI n’a pas désactivé le démarrage sécurisé. Vérifiez les paramètres du micrologiciel ou exécutez mokutil --sb-state, et ces machines se feront un plaisir de vous informer que Secure Boot est toujours activé. Mais un paramètre de micrologiciel obscur, « Politique d’exécution d’image » est défini sur « Toujours exécuter » – donc Secure Boot vérifierait toujours la signature sur la pile de démarrage, puis la démarrerait indépendamment de ce qui a été trouvé. Je citerai juste le découvreur, [Dawid Potocki]La conclusion de : « Ne croyez pas que les fonctionnalités de sécurité que vous avez activées fonctionnent, TESTEZ-LES ! »

RCE de QT Vulnérabilité Punaise

La suite QT a un problème, où Javascript intégré dans le code QML (Qt Modeling Language) pourrait déclencher l’un des deux problèmes de gestion de la mémoire et atteindre RCE. Il y a un peu de désaccord entre Cisco Talos et QT, quant à savoir s’il s’agit d’un simple bogue ou d’une vulnérabilité de sécurité. Le code QML est explicitement destiné à être un code d’interface utilisateur pour les applications et ne doit jamais exécuter de code non approuvé. En fait, selon QT, la vulnérabilité de sécurité serait toute « application qui transmet une entrée non fiable à QtQml ».