Ils ont trouvé une vulnérabilité dans Python qui permet d'exécuter des commandes à partir de scripts en bac à sable

Il ya quelques jours a divulgué une méthode pour contourner les systèmes d'exécution de code isolés de Python, basé sur l'utilisation d'un bogue connu de longue date apparu dans Python 2.7, identifié en 2012, et non encore corrigé dans Python 3.

Il est mentionné que le bogue permet d'utiliser du code python spécialement lié pour lancer un appel à la mémoire déjà libérée (Use-After-Free) en Python. Initialement, on supposait que l'erreur ne représentait pas une menace pour la sécurité et que dans de très rares cas, généralement créés artificiellement, elle pouvait entraîner une fin anormale du script.

Un chercheur en sécurité sous le pseudonyme kn32 s'est intéressé au problème et a réussi à préparer un exploit fonctionnel qui permet d'appeler n'importe quelle commande système sans accès direct à des méthodes comme os.system.

L'exploit est implémenté en Python pur et fonctionne sans importer de bibliothèques externes et sans installer le pilote "code.__new__". Parmi les crochets, seul "builtin.__id__" est utilisé, ce qui n'est généralement pas interdit. Sur le plan pratique, le code proposé peut être utilisé pour contourner les mécanismes d'isolation dans divers services et environnements (par exemple, dans les environnements d'apprentissage, les shells en ligne, les contrôleurs intégrés, etc.) qui permettent l'exécution de code Python, mais limitent la disponibilité appels et interdire les méthodes d'accès telles que os.system.

Le code proposé est un analogue de l'appel os.system, qui fonctionne en exploitant une vulnérabilité dans CPython. L'exploit fonctionne avec toutes les versions de Python 3 sur les systèmes x86-64 et est stable sur Ubuntu 22.04 même avec les modes de sécurité PIE, RELRO et CET activés.

Le travail revient à obtenir des informations sur l'adresse d'une des fonctions à partir du code Python dans le code exécutable CPython.

Sur la base de cette adresse, l'adresse de base de CPython en mémoire et l'adresse de la fonction system() dans l'instance libc chargée sont calculées. A la fin, une transition directe vers un système d'adressage donné est lancée en remplaçant le pointeur du premier argument par la chaîne "/bin/sh".

L'approche la plus simple d'exploitation consiste à créer une liste d'une longueur égale à la longueur du tampon libéré, qui aura très probablement son tampon d'éléments (ob_item) alloué au même endroit que le tampon libéré.

Cela signifie que nous aurons deux "vues" différentes sur le même morceau de mémoire. Une vue, la vue mémoire, pense que la mémoire n'est qu'un tableau d'octets, dans lequel nous pouvons écrire ou lire arbitrairement. La deuxième vue est la liste que nous avons créée, qui pense que la mémoire est une liste de pointeurs PyObject. Cela signifie que nous pouvons créer de faux e-mails PyObject quelque part en mémoire, écrire leurs adresses dans la liste en écrivant dans la memoryview, puis y accéder en indexant la liste.

Dans le cas du PoC, ils écrivent 0 dans le tampon (ligne 16) puis y accèdent avec print(L[0]). L[0] obtient le premier PyObject* qui est 0, puis print essaie d'accéder à certains champs de celui-ci, ce qui entraîne un déréférencement de pointeur nul.

Il est mentionné que ce bogue est présent dans toutes les versions de python depuis au moins python 2.7 et bien que l'exploit ait été conçu pour fonctionner sur presque toutes les versions de Python 3, cela ne signifie pas qu'il n'est pas reproductible dans Python 2 (selon l'auteur).

Le but de l'exploit est d'appeler system("/bin/sh") dont les étapes sont les suivantes :

  • Pointeur de fonction binaire de fuite CPython
  • Calculer l'adresse de base CPython
  • Calculez l'adresse du système ou votre talon PLT
  • Aller à cette adresse avec le premier argument pointant vers /bin/sh
  • Gagner

Enfin, il est mentionné que l'exploit ne sera pas utile dans la plupart des configurations. Cependant, cela peut être utile pour les interpréteurs Python qui tentent d'isoler du code, de restreindre les importations ou l'utilisation d'Audit Hooks.

Enfin si vous souhaitez en savoir plus sur la note, vous pouvez consulter la publication originale dans le lien suivant


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.