Cette semaine en sécurité : Pacman, Hetzbleed et la mort d’Internet Explorer

Il n’y a pas une, mais deux attaques secondaires dont il faut parler cette semaine. Le premier est Pacman, un contournement pour le code d’authentification du pointeur d’ARM. PAC est une protection intégrée à certains processeurs ARM, où une valeur de hachage cryptographique doit être correctement définie lors de la mise à jour des pointeurs. Si le hachage n’est pas défini correctement, le programme plante simplement. L’idée est que la plupart des exploits utilisent la manipulation du pointeur pour réaliser l’exécution du code, et la définition correcte du PAC nécessite un appel d’instruction explicite. Le PAC est en fait indiqué dans les bits inutilisés du pointeur lui-même. L’architecture AArch64 utilise des valeurs 64 bits pour l’adressage, mais l’espace d’adressage est bien inférieur à 64 bits, généralement 53 bits ou moins. Cela laisse 11 bits pour la valeur PAC. Gardez à l’esprit que l’application ne détient pas les clés et ne calcule pas cette valeur. 11 bits peuvent ne pas sembler suffisants pour sécuriser cela, mais gardez à l’esprit que chaque tentative infructueuse plante le programme et que chaque redémarrage de l’application régénère les clés.

Ce que Pacman introduit est un oracle, qui est une méthode pour mieux comprendre les données que l’attaquant ne devrait pas pouvoir voir. Dans ce cas, l’oracle fonctionne via des attaques de spéculation, très similaires à Meltdown et Spectre. La clé est de tenter un déréférencement de pointeur protégé de manière spéculative, puis d’observer le changement d’état du système en conséquence. Ce que vous remarquerez peut-être, c’est que cela nécessite qu’une attaque exécute déjà du code sur le système cible, afin d’exécuter la technique oracle PAC. Pacman n’est pas un défaut d’exécution de code à distance et n’est pas non plus utile pour obtenir RCE.

Une autre remarque importante est qu’une application doit avoir un support PAC compilé, afin de bénéficier de cette protection. La plate-forme qui a largement utilisé PAC est MacOS, car il s’agit d’une fonctionnalité intégrée à leur processeur M1. La chaîne d’attaque commencerait probablement par un bogue d’exécution à distance dans une application manquant le support PAC. Une fois qu’un pied est établi dans l’espace utilisateur privilégié, Pacman serait utilisé dans le cadre d’un exploit contre le noyau. Voir le document PDF pour tous les détails.

Hertzbleed

L’autre technique de canal latéral est une nouvelle approche d’une vieille idée. Hertzbleed est basé sur l’idée qu’il est possible de détecter la différence entre un processeur fonctionnant à la fréquence de base et ce processeur fonctionnant à une fréquence de suralimentation. La différence entre ces deux états peut en fait laisser échapper des informations sur ce que fait le processeur. Il y a un PDF de pré-version de leur article pour vérifier les détails. Le résultat le plus important est que la protection standard contre les attaques temporelles, la programmation en temps constant, n’est pas toujours une mesure de sécurité fiable.

Cela fonctionne parce que la fréquence maximale dépend de la puissance de conception thermique (TDP) du processeur, de la quantité maximale de puissance qu’un processeur est conçu pour utiliser et de la quantité de chaleur à dissiper. Différentes instructions utiliseront en fait différentes quantités d’énergie et généreront plus ou moins de chaleur en fonction de cela. Plus de chaleur signifie un étranglement plus précoce. Et la limitation peut être détectée dans les temps de réponse. Les détails de cela sont assez fascinants. Saviez-vous que même l’exécution des mêmes instructions, avec des valeurs de registre différentes, entraîne une consommation électrique légèrement différente ? Ils ont choisi un algorithme cryptographique unique, SIKE, une technique d’échange de clés à sécurité quantique, et ont tenté d’extraire la clé secrète d’un serveur par le biais d’attaques temporelles.

Il y a une bizarrerie dans SIKE, également découverte et divulguée dans cette recherche, qu’il est possible de court-circuiter une partie de l’algorithme, de sorte qu’une série d’étapes intermédiaires internes aboutissent à une valeur de zéro. Si vous connaissez plusieurs bits consécutifs de la clé statique, il est possible de construire un défi qui répond à cette bizarrerie. Par extension, vous pouvez deviner le prochain bit inconnu, et il ne tombera dans la bizarrerie que si vous avez bien deviné. SIKE utilise la programmation en temps constant, donc ce comportement étrange ne devrait pas avoir d’importance. Et ici, l’observation de Hertzbleed est prise en compte. L’algorithme SIKE consomme moins d’énergie lors d’une exécution contenant ce comportement de zéro en cascade. Consommer moins d’énergie signifie que le processeur peut rester à plein régime plus longtemps, ce qui signifie que l’échange de clé se termine un peu plus rapidement. Assez pour qu’il puisse être détecté même via une connexion réseau. Ils ont testé la bibliothèque CIRCL de Cloudflare et PQCrypto-SIDH de Microsoft, et ont pu récupérer les clés secrètes des deux implémentations, en 36 et 89 heures respectivement.

Il existe une atténuation contre ce défaut particulier, où il est possible de détecter une valeur de défi qui pourrait déclencher les zéros en cascade, et de bloquer cette valeur avant que tout traitement ne se produise. Il sera intéressant de voir si des bizarreries dans d’autres algorithmes peuvent être découvertes et militarisées en utilisant cette même technique. Malheureusement, du côté du processeur, la seule véritable atténuation consiste à désactiver complètement les horloges de suralimentation, ce qui a un effet négatif important sur les performances du processeur.

Vaincre Nest Secure Boot

[Frédéric Basse] a un Google Nest Hub, et il voulait vraiment exécuter sa propre distribution Linux dessus. Il y a un problème, cependant. Le Nest utilise un démarrage sécurisé et il n’existe aucun moyen officiel de déverrouiller le chargeur de démarrage. Depuis quand un hacker dévoué laisserait-il cela l’arrêter ? La première étape consistait à trouver une interface UART, cachée sur certains canaux non terminés d’un câble ruban. Un tableau de bord personnalisé plus tard, et il avait un journal U-Boot. Ensuite, il fallait parcourir les combinaisons de boutons de démarrage et voir ce que U-Boot essayait de faire avec chacun. L’une de ces combinaisons permet de démarrer à partir d’un fichier recovery.img, ce qui serait idéal, sinon pour un démarrage sécurisé.

La grande chose à propos de U-Boot est qu’il est Open Source sous GPL, ce qui signifie que le code source doit être disponible pour lecture. Trouvez un bogue dans cette source et vous avez votre contournement de démarrage sécurisé. L’Open Source permet également certaines approches amusantes, comme l’exécution de parties du code U-Boot dans l’espace utilisateur et l’exercice avec un fuzzer. C’est l’approche qui a trouvé un bogue, où une taille de bloc supérieure à 512 octets déclenche un débordement de tampon. C’est une hypothèse généralement sûre, car il n’y a pas vraiment de périphériques de stockage USB avec une taille de bloc supérieure à 512.

N’ayez crainte, un appareil comme le Raspberry Pi Pico peut exécuter TinyUSB, ce qui permet d’émuler un périphérique USB avec la taille de bloc que vous spécifiez. Un test a déterminé que cette approche entraînait un plantage reproductible sur l’appareil réel. L’exécution du code est assez simple, écrivant un tas d’instructions qui sont essentiellement noop codes pointant vers une charge utile, puis écrasant le pointeur de retour. L’exécution du code dans la boîte, il ne restait plus qu’à écraser la liste de commandes et à exécuter un script U-Boot personnalisé. Une chose de beauté.

ping

Les humbles ping commande. Combien une seule paire de paquets peut-elle nous en dire sur un réseau et un hôte distant ? Selon [HD Moore], un peu. Par exemple, prenez le temps donné pour une réponse ping et calculez une distance basée sur 186 miles par milliseconde. C’est la distance maximale absolue à laquelle se trouve l’hôte, bien qu’un quart et la moitié de ce montant soient des limites inférieure et supérieure raisonnables pour une estimation de distance. Le TTL a très probablement commencé à 64, 128 ou 255, et vous pouvez très bien deviner les sauts rencontrés en cours de route. Oh, et si cette réponse a commencé à 64, il s’agit probablement d’une machine Linux, 128 pour Windows, et 255 indique généralement un système d’exploitation dérivé de BSD.

Recevoir un message « hôte de destination inaccessible » est intéressant en soi et vous renseigne sur le routeur qui devrait pouvoir atteindre l’adresse IP donnée. Ensuite, il y a l’adresse IP de diffusion, qui envoie le message à chaque adresse IP du sous-réseau. Utiliser quelque chose comme Wireshark pour la capture de paquets est éclairant ici. La commande elle-même ne peut afficher qu’une seule réponse, même si plusieurs périphériques peuvent avoir répondu. Chacune de ces réponses a une adresse MAC qui peut être consultée pour déterminer le fournisseur. Une autre astuce intéressante consiste à usurper l’adresse IP source d’un paquet ping, en utilisant une machine que vous contrôlez avec une adresse IP publique. Ping chaque appareil sur le réseau, et beaucoup d’entre eux enverront la réponse via leur passerelle par défaut. Vous pourriez trouver une connexion Internet ou un VPN qui n’est pas censé être là. Qui savait que tu pouvais tant apprendre des humbles ping.

Bits et octets

Internet Explorer est vraiment, vraiment, mort. Si vous aviez l’impression, comme moi, qu’Internet Explorer a été retiré il y a des années, alors il peut être surprenant de savoir que cela a finalement été fait la semaine dernière. Le patch de ce mois-ci mardi était le dernier jour où IE était officiellement pris en charge, et à partir de maintenant, il est totalement non pris en charge et devrait éventuellement être automatiquement désinstallé des machines Windows 10. Le correctif de Follina, ainsi que quelques autres correctifs importants, sont également à venir dans le patch de ce mois-ci.

Il y a un nouveau record pour les attaques HTTPS DDOS, établi la semaine dernière : Cloudflare a atténué une attaque composée de 26 millions de requêtes par seconde. Les attaques HTTPS sont un coup de poing consistant à la fois en une saturation des données brutes et en un épuisement des ressources du serveur. L’attaque provenait d’un botnet de machines virtuelles et de serveurs, la plus grande tranche provenant d’Indonésie.

Vous utilisez le niveau gratuit de Travis CI ? Saviez-vous que vos logs sont accessibles au monde entier via un appel API Travis ? Et en plus, tout l’historique des courses depuis 2013 semble être disponible. Il est peut-être temps d’aller révoquer certaines clés d’accès. Travis tente de censurer les jetons d’accès, mais bon nombre d’entre eux passent quand même le tamis.

Vous êtes-vous déjà demandé à quoi ressemble la matrice des risques pour le reniflage de clé TPM au démarrage ? Ce n’est pas joli. Les chercheurs de Secura ont examiné six applications de cryptage et de démarrage sécurisé populaires, et aucune d’entre elles n’a utilisé les fonctionnalités de cryptage des paramètres qui chiffreraient les clés sur le réseau. La conclusion ironique ? Les puces TPM discrètes sont moins sécurisées que celles intégrées au micrologiciel de la carte mère.

François Zipponi
Je suis François Zipponi, éditorialiste pour le site 10-raisons.fr. J'ai commencé ma carrière de journaliste en 2004, et j'ai travaillé pour plusieurs médias français, dont le Monde et Libération. En 2016, j'ai rejoint 10-raisons.fr, un site innovant proposant des articles sous la forme « 10 raisons de... ». En tant qu'éditorialiste, je me suis engagé à fournir un contenu original et pertinent, abordant des sujets variés tels que la politique, l'économie, les sciences, l'histoire, etc. Je m'efforce de toujours traiter les sujets de façon objective et impartiale. Mes articles sont régulièrement partagés sur les réseaux sociaux et j'interviens dans des conférences et des tables rondes autour des thèmes abordés sur 10-raisons.fr.