Paar dagen geleden heeft een methode onthuld om de geïsoleerde code-uitvoeringssystemen van Python te omzeilen, gebaseerd op het gebruik van een lang bekende bug die verscheen in Python 2.7, geïdentificeerd in 2012 en nog niet opgelost in Python 3.
Er wordt gezegd dat de bug maakt het mogelijk om speciaal gebonden python-code te gebruiken om een oproep te starten naar geheugen dat al is vrijgemaakt (Use-After-Free) in Python. Aanvankelijk werd aangenomen dat de fout geen veiligheidsrisico vormt en slechts in zeer zeldzame gevallen, meestal kunstmatig gecreëerd, kan deze leiden tot een abnormale beëindiging van het script.
Een beveiligingsonderzoeker onder het pseudoniem kn32 raakte geïnteresseerd in het probleem en slaagde erin een functionele exploit voor te bereiden die het mogelijk maakt om elk systeemcommando aan te roepen zonder directe toegang tot methoden zoals os.system.
De exploit is geïmplementeerd in pure Python en werkt zonder externe bibliotheken te importeren en zonder het stuurprogramma "code.__new__" te installeren. Van de hooks wordt alleen "builtin.__id__" gebruikt, wat over het algemeen niet verboden is. Praktisch gezien kan de voorgestelde code worden gebruikt om isolatiemechanismen te omzeilen in verschillende diensten en omgevingen (bijvoorbeeld in leeromgevingen, online shells, ingebouwde controllers, enz.) die uitvoering van Python-code mogelijk maken, maar de beschikbare oproepen en staan geen toegangsmethoden zoals os.system toe.
De voorgestelde code is een analoog van de os.system-aanroep, die werkt door misbruik te maken van een kwetsbaarheid in CPython. De exploit werkt met alle versies van Python 3 op x86-64-systemen en is stabiel op Ubuntu 22.04, zelfs met PIE-, RELRO- en CET-beveiligingsmodi ingeschakeld.
werk komt neer op het verkrijgen van informatie over het adres van een van de functies uit de Python-code in de uitvoerbare code van CPython.
Op basis van dit adres worden het basisadres van CPython in het geheugen en het adres van de system()-functie in de geladen libc-instantie berekend. Aan het einde wordt een directe overgang naar een bepaald adressysteem gestart door de aanwijzer van het eerste argument te vervangen door de tekenreeks "/bin/sh".
De gemakkelijkste benadering van exploitatie is om een lijst te maken met een lengte die gelijk is aan de lengte van de vrijgemaakte buffer, die hoogstwaarschijnlijk de itembuffer (ob_item) toegewezen krijgt op dezelfde plaats als de vrijgemaakte buffer.
Dit betekent dat we twee verschillende "views" op hetzelfde stuk geheugen krijgen. Eén weergave, de geheugenweergave, denkt dat geheugen slechts een reeks bytes is, waarnaar we willekeurig kunnen schrijven of lezen. De tweede weergave is de lijst die we hebben gemaakt, die denkt dat geheugen een lijst met PyObject-aanwijzers is. Dit betekent dat we valse PyObject-e-mails ergens in het geheugen kunnen maken, hun adressen naar de lijst kunnen schrijven door naar de geheugenweergave te schrijven en ze vervolgens kunnen openen door de lijst te indexeren.
In het geval van de PoC schrijven ze 0 naar de buffer (regel 16) en openen deze vervolgens met print(L[0]). L[0] krijgt het eerste PyObject* dat 0 is, en print probeert vervolgens toegang te krijgen tot enkele velden erin, wat resulteert in een null pointer dereferentie.
Er wordt gezegd dat deze bug is aanwezig in alle python-versies sinds ten minste python 2.7 en hoewel de exploit is ontworpen om te werken op bijna elke versie van Python 3, betekent dit niet dat het niet reproduceerbaar is in Python 2 (volgens de auteur).
Het doel van de exploit is om system("/bin/sh") aan te roepen waarvan de stappen als volgt zijn:
- CPython lek binaire functieaanwijzer
- Bereken CPython-basisadres
- Bereken het adres van het systeem of uw PLT-stub
- Spring naar dit adres met het eerste argument dat verwijst naar /bin/sh
- overwinning
Ten slotte wordt vermeld dat de exploit in de meeste configuraties niet nuttig zal zijn. Het kan echter nuttig zijn voor Python-interpreters die code proberen te isoleren, invoer beperken of het gebruik van Audit Hooks.
Eindelijk als u er meer over wilt weten over de notitie kunt u de originele publicatie raadplegen in de volgende link.