Ils ont trouvé une vulnérabilité dans openSSH 9.1 qui permet de contourner malloc

Qualys (une société technologique spécialisée dans la sécurité du cloud) a récemment annoncé avoir trouvé un moyen de contourner malloc et la protection no-double pour initier un transfert de code en utilisant une vulnérabilité dans OpenSSH 9.1.

À ce jour, cette vulnérabilité a été jugée purement théorique, car il est peu probable qu'elle puisse donner lieu à une exploitation fonctionnelle. Cependant, la possibilité d'en créer une reste une question importante.

Concernant la vulnérabilité, il est mentionné que l'astuce pour contourner les protections contre la double libération et l'utilisation après libération de malloc consiste à réaffecter la mémoire occupée par options.kex_algorithms dès qu'elle 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 :

Cette vulnérabilité provient d'une double libération de mémoire lors de la phase de pré-authentification. Pour la reproduire, il suffit de modifier la bannière du client SSH en « SSH-2.0-FuTTYSH_9.1p1 » (ou une autre version plus ancienne) afin d'activer la configuration des options « SSH_BUG_CURVE25519PAD » et « SSH_OLD_DHGEX ». Après avoir activé ces options, la mémoire du tampon « options.kex_algorithms » est libérée deux fois.

Lors de l'exploitation de cette vulnérabilité, les chercheurs de Qualys ont pu prendre le contrôle du registre du processeur « %rip », qui contient un pointeur vers la prochaine instruction à exécuter. La technique d'exploitation qu'ils ont développée leur 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 non mis à jour, fourni 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.

Les prochaines étapes, dont la faisabilité reste à déterminer, sont les suivantes :

– é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).

On constate que le prototype proposé ne met en œuvre que la première étape de l'attaque : pour créer une exploitation fonctionnelle, il est nécessaire de contourner les mécanismes de protection ASLR, NX et ROP, et de sortir de l'isolation 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 trouverez les détails en suivant ce lien.