Kilka dni temu ujawnił metodę omijania izolowanych systemów wykonywania kodu Pythona, oparty na wykorzystaniu znanego od dawna błędu, który pojawił się w Pythonie 2.7, zidentyfikowany w 2012 roku i nie naprawiony jeszcze w Pythonie 3.
Wspomina się, że błąd pozwala na użycie specjalnie powiązanego kodu Pythona do zainicjowania połączenia do pamięci już zwolnionej (Użyj po zwolnieniu) w Pythonie. Początkowo zakładano, że błąd nie stanowi zagrożenia bezpieczeństwa i tylko w bardzo rzadkich przypadkach, zwykle sztucznie wytworzonych, może prowadzić do nieprawidłowego zakończenia skryptu.
Problemem zainteresował się badacz bezpieczeństwa o pseudonimie kn32 i udało mu się przygotować funkcjonalny exploit, który umożliwia wywołanie dowolnej komendy systemowej bez bezpośredniego dostępu do metod takich jak os.system.
Exploit jest zaimplementowany w czystym Pythonie i działa bez importowania zewnętrznych bibliotek i bez instalowania sterownika "code.__new__". Z haczyków używany jest tylko „builtin.__id__”, co generalnie nie jest zabronione. Od strony praktycznej proponowany kod można wykorzystać do ominięcia mechanizmów izolacji w różnych usługach i środowiskach (np. w środowiskach edukacyjnych, powłokach online, wbudowanych kontrolerach itp.), które pozwalają na wykonanie kodu Pythona, ale ograniczają dostępne wywołuje i blokuje metody dostępu, takie jak os.system.
Proponowany kod jest odpowiednikiem wywołania os.system, który działa poprzez wykorzystanie luki w CPython. Exploit działa ze wszystkimi wersjami Pythona 3 na systemach x86-64 i jest stabilny na Ubuntu 22.04, nawet z włączonymi trybami bezpieczeństwa PIE, RELRO i CET.
Praca sprowadza się do uzyskania informacji o adresie jednej z funkcji z kodu Pythona w kodzie wykonywalnym CPython.
Na podstawie tego adresu obliczany jest adres bazowy CPythona w pamięci oraz adres funkcji system() w załadowanej instancji libc. Na koniec następuje bezpośrednie przejście do danego systemu adresowego poprzez zastąpienie wskaźnika pierwszego argumentu napisem "/bin/sh".
Najłatwiejszym podejściem do eksploatacji jest utworzenie listy o długości równej długości zwolnionego bufora, która najprawdopodobniej będzie miała swój bufor pozycji (ob_item) przydzielony w tym samym miejscu, co zwolniony bufor.
Oznacza to, że otrzymamy dwa różne „widoki” na ten sam fragment pamięci. Jeden pogląd, widok pamięci, uważa, że pamięć to po prostu tablica bajtów, do których możemy arbitralnie zapisywać lub czytać. Drugi widok to utworzona przez nas lista, według której pamięć jest listą wskaźników PyObject. Oznacza to, że możemy tworzyć fałszywe wiadomości e-mail PyObject gdzieś w pamięci, zapisywać ich adresy na liście, pisząc do widoku pamięci, a następnie uzyskiwać do nich dostęp poprzez indeksowanie listy.
W przypadku PoC zapisują 0 do bufora (linia 16), a następnie uzyskują do niego dostęp poprzez print(L[0]). L[0] pobiera pierwszy obiekt PyObject*, który ma wartość 0, a następnie print próbuje uzyskać dostęp do niektórych znajdujących się w nim pól, co skutkuje wyłuskaniem wskaźnika zerowego.
Wspomina się, że ten błąd jest obecny we wszystkich wersjach Pythona od przynajmniej Pythona 2.7 i chociaż exploit został zaprojektowany do pracy na prawie każdej wersji Pythona 3, nie oznacza to, że nie można go odtworzyć w Pythonie 2 (według autora).
Celem exploita jest wywołanie systemu("/bin/sh") których kroki są następujące:
- Wskaźnik funkcji binarnej wycieku CPython
- Oblicz adres bazowy CPython
- Oblicz adres systemu lub swój odcinek PLT
- Przejdź do tego adresu z pierwszym argumentem wskazującym na /bin/sh
- wygrana
Na koniec wspomniano, że exploit nie będzie przydatny w większości konfiguracji. Może się jednak przydać interpreterom Pythona próbującym izolować kod, ograniczać importy lub korzystać z zaczepów audytu.
W końcu jeśli chcesz dowiedzieć się więcej na ten temat o notatce można zapoznać się z oryginalną publikacją w następujący link.