Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.
Récemment Qualys (une entreprise technologique spécialisée dans la sécurité du cloud) dévoilé qu'as-tu trouvé un moyen de contourner malloc et une protection sans double pour initier un croisement en utilisant une vulnérabilité dans OpenSSH 9.1.
Jusqu'à présent, il a été déterminé que une telle vulnérabilité n'est que "théorique", car il est peu probable qu'il crée un exploit fonctionnel. Dans le même temps, la possibilité de créer un exploit fonctionnel reste une grande question.
Concernant la vulnérabilité, il est mentionné que l'astuce pour contourner les protections double gratuit et utilisation après gratuit de malloc est de réallouer la mémoire qui était occupée par options.kex_algorithms dès qu'il est libre.
Du point de vue de malloc, aucune tentative n'est faite pour libérer, lire ou écrire de la mémoire qui est déjà libre ; du point de sshd, cependant, une attaque d'aliasing se produit, puisque deux pointeurs différents vers deux objets différents se réfèrent au même bloc de mémoire, et une écriture sur un objet écrase l'autre objet.
Cela ouvre un monde de possibilités.
Nous avons commencé notre enquête sur le rat de bibliothèque Debian (qui utilise le code glibc
malloc), mais nous sommes finalement passés à OpenBSD 7.2, car OpenBSD
malloc (malgré sa programmation très défensive) a deux fonctionnalités qui
rendez-le particulièrement intéressant pour ce double bogue gratuit :
La vulnérabilité est due à une double version d'une zone mémoire en phase de pré-authentification. Pour créer les conditions de la vulnérabilité, changez simplement la bannière du client SSH à "SSH-2.0-FuTTYSH_9.1p1" (ou un autre ancien client SSH) pour obtenir le réglage des drapeaux "SSH_BUG_CURVE25519PAD" et "SSH_OLD_DHGEX" Après avoir réglé ces drapeaux, la mémoire pour le tampon "options.kex_algorithms" est libérée deux fois.
Chercheurs Qualys, au cours de la manipulation de la vulnérabilité, ont pu prendre le contrôle du registre du processeur "% rip", A contenant un pointeur vers la prochaine instruction à exécuter. La technique d'exploit développée permet de transférer le contrôle à n'importe quel point de l'espace d'adressage du processus sshd dans un environnement OpenBSD 7.2 obsolète, qui est livré par défaut avec OpenSSH 9.1.
Mise à jour rapide : nous avons pu obtenir un contrôle arbitraire du "rip" via ce bogue (c'est-à-dire que nous pouvons sauter où nous voulons dans sshd espace d'adressage) sur une installation non corrigée d'OpenBSD 7.2 (exécutant
OpenSSH 9.1 par défaut). Ce n'est en aucun cas la fin de l'histoire : cette ePour juste l'étape 1, sautez le malloc et les doubles gardes.Ce qui suit étape qui peut ou non être réalisable du tout, sont :
– étape 2, exécuter du code arbitraire malgré ASLR, NX et ROP
protections (cela nécessitera probablement une fuite d'informations, soit
par la même erreur ou par une erreur secondaire) ;– étape 3, sortie du bac à sable sshd (via un bug mineur, soit dans
le processus parent privilégié ou dans l'attaque réduite du noyau
surface).
Il est à noter que le prototype proposé n'est la mise en œuvre que de la première étape de l'attaque : Pour créer un exploit fonctionnel, vous devez contourner les mécanismes de protection ASLR, NX et ROP et sortir de l'isolement du bac à sable, ce qui est peu probable.
Résoudre le problème du contournement d'ASLR, NX et ROP nécessite d'obtenir des informations d'adresse, ce qui peut être accompli en identifiant une autre vulnérabilité qui entraîne une fuite d'informations. Un bogue dans un parent privilégié ou un processus noyau peut aider à sortir du bac à sable.
La vulnérabilité est mentionnée pour fonctionner comme suit :
- -Tout d'abord, options.kex_algorithms gratuites dans compat_kex_proposal(), en prétendant que le client ssh est un ancien client "FuTTY".
- -Deuxièmement, le fragment qui était occupé par options.kex_algorithms est réalloué, avec une structure EVP_AES_KEY dont la taille est de 264 octets, en sélectionnant le chiffrement « aes128-ctr » lors de la phase d'échange de clé. Cette réallocation se produit avec une probabilité d'environ 1/32.
- – Troisièmement, libérer (encore) le morceau qui était occupé par options.kex_algorithms (et est maintenant occupé par la structure EVP_AES_KEY) dans kex_assemble_names() (via mm_getpwnamallow()). Cela se produit si et seulement si le premier octet du bloc est '+', '-' ou '^' (sinon kex_assemble_names() renvoie une erreur et fatal_fr() est appelée).
- – Quatrièmement, le morceau qui était occupé par options.kex_algorithms (et qui est toujours référencé comme une structure EVP_AES_KEY maintenant) est réaffecté, avec une chaîne d'octets 'A' de 300, "authctxt->user" ou "authctxt ->style" pendant le phase d'authentification. Cette réallocation, qui écrase effectivement toute la structure EVP_AES_KEY avec des octets "A", se produit avec une probabilité d'environ 2/32.
- – Enfin, il saute à 0x4141414141414141 lorsque sshd appelle EVP_Cipher(), car la structure EVP_AES_KEY contient un pointeur de fonction qui a été écrasé par nos octets 'A' et est appelé par CRYPTO_ctr128_encrypt_ctr32() (via EVP_Cipher()) .
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.