Wyjaśnienie metody ataku blokowanego przez CET

Question

Przeczytałem artykuł ‟A Te­ch­ni­cal Lo­ok at In­tel’s Con­trol-flow En­fo­r­ce­ment Te­ch­nolo­gy” i zastanawiam się, w jaki sposób instrukcje, jakie są pokazane na rysunku 2, mogą być zinterpretowane od innego adresu zanim wykorzystano tak powstałą instrukcję “ret”. A jeśli zmodyfikowano adres powrotu na stosie i wykorzystano instrukcję “ret” obecną przy interpretacji z oryginalnego adresu, to po co jeszcze kolejna instrukcja “ret”? Opis pierwszej części: “Re­tu­rn Orien­ted Program­ming”.

Comments

(coś jest nie tak z linkiem)

---

Już poprawiony. Wysyłałem drugi raz formularz po wypełnieniu brakującego pola i pewnie dlatego się coś zmieniło.

Answer 1

ROP/ret2lib/zwał to nie tyle metoda "ataku" (co jest dość wysokopoziomowym określeniem na cały proces), co exploitacji. Żeby w ogóle dojść w procesie exploitacji do ROP trzeba najpierw mieć dwie rzeczy:

1. Możliwość wykonania kodu spod wskazanego adresu (tj. kontrolowane RIP/EIP/IP/PC, słynne 41414141).
2. Kontrolowany stos (konkretniej, kontrolowana zawartość stosu).

Spełnienie tych warunków albo dostaje się gratis z uwagi na rodzaj błędu, który się exploituje (jak np. stack-based buffer overflow), albo trzeba do tego doprowadzić we wcześniejszych krokach procesu exploitacji (np. w błędach klasy use-after-free możemy często dostać tzw write-what-where - czyli możliwość zapisania kontrolowanej wartości w kontrolowane miejsce w pamięci, a z tego z kolei można przejść do wykonania kodu z ograniczeniem do jednego gadżetu, z tego do stack pivot - co nam daje kontrolowany stos przez de fact zmianę regionu który nazywany stosem, i dopiero wtedy docieramy do ROP).

Ale ostatecznie docieramy do momentu kiedy możemy stosować ROP, jak i do odpowiedzi na pierwsze pytanie:

w jaki sposób instrukcje, jakie są pokazane na rysunku 2, mogą być zinterpretowane od innego adresu zanim wykorzystano tak powstałą instrukcję “ret”

Zgodnie z pierwszym wymaganiem ROP, musimy już w tym momencie móc powiedzieć który kod ma się zacząć wykonywać, tj. w jakiś sposób wymusić skok we wskazane miejsce. Co za tym idzie, możemy po prostu wskazać miejsce w środku instrukcji. To nie jest coś co ROP daje, to jest coś co jest wstępnym wymaganiem ROP.

 po co jeszcze kolejna instrukcja “ret”?

ROP polega na "chainowaniu" (łączeniu w łańcuch) wielu gadżetów (kawałków kodu zakończonych instrukcją ret lub ekwiwalentem), tak, żeby zrobić coś więcej niż wykonać te kilka instrukcji przed ret. Jak się ma dużo gadżetów, to można sobie je tak połączyć, żeby np. zaalokować pamięć z prawami RWX, doczytać z socketu sieciowego dodatkowy shellcode tam, i go wykonać (bez restrykcji, które ma ROP).

Więc to co oni tam pokazują, to po prostu kilka różnych gadżetów, które najczęściej kończą się na C3 (ret).

W praktyce ROP to po prostu podanie wielu adresów powrotu na stosie, które są następnie potem zczytywane przez kolejne rety z kolejnych gadżetów w łańcuchu (gdzie łańcuch jest definiowany właśnie przez te adresy na stosie). Te adresy jeszcze są przeplatane argumentami / dopełnianiami btw.

100 lat temu opisałem to trochę bardziej na blogu, ale chyba używałem wtedy trochę innej terminologii jeszcze niż obecnie przyjęty "gadżet". Anyway: https://gynvael.coldwind.pl/?id=144

Comments

Bardzo ciekawe zagadnienie. Nie interesuję się raczej, jak to wykorzystać, ale jak pisać oprogramowanie, by tego nie dało się wykorzystać. Ale uświadomiłeś mi, że mimo starań jest mnóstwo sposobów, by użyć tej techniki wykonania niechcianego kodu.

Niedawno otrzymałem aktualizację zestawu narzędzi kompilacji w systemie Gentoo Linux, która włącza “Control-flow Enforcement Technology” dla wszystkich programów w systemie, i rozważałem, czy jest sens z tego korzystać kosztem trochę większych plików wykonywalnych.

Ciekawym zagadnieniem jest również “ret‐to‐anything” służące do bezpośredniego wywołania funkcji z biblioteki standardowej.

W przypadku błędów w programie polegających na przepełnieniu bufora można było tylko liczyć na to, że nie będzie możliwości napisania ‘exploita’ z tego powodu, że program się ‚wywali’ jeszcze w kodzie oryginalnej funkcji, przed dotarciem do instrukcji “ret”, z powodu nadpisania jakichś zmiennych lokalnych nieprawidłowymi wartościami. Teraz, z aktywnym zabezpieczeniem, wykorzystanie tej techniki nie będzie możliwe.

---

Nie interesuję się raczej, jak to wykorzystać, ale jak pisać oprogramowanie, by tego nie dało się wykorzystać.

Od strony programisty C/C++ po prostu trzeba się starać nie robić błędów, a tworząc biblioteki/programy też myśleć o tym, żeby wszystko było secure-by-default (tj. defaultowe opcje/eksportowane funkcje były bezpieczne do użycia). A utrudnianie exploitacji / etc to domena twórców kompilatorów / OSów / CPU.

Zresztą, lepiej użyć po prostu Rust/Go/itp ;)

Ciekawym zagadnieniem jest również “ret‐to‐anything” służące do bezpośredniego wywołania funkcji z biblioteki standardowej.

Powiedzmy że to jest część ROP, tj. ROP jest jakby super-setem ret2libc, etc. Technicznie ROP jest turning-complete, tj. można w tym robić pętle, skoki warunkowe, etc. Można to też do obfuskacji programów używać (mam gdzieś naklepane "reverse-me" gdzie cały program to de facto return który wskakuje w ROP chain, w którym z kolei jest implementacja prostej VMki, a faktyczna funkcjonalność w bytecode tej VMki).

W przypadku błędów w programie polegających na przepełnieniu bufora można było tylko liczyć na to, że nie będzie możliwości napisania ‘exploita’ z tego powodu, że program się ‚wywali’ jeszcze w kodzie oryginalnej funkcji, przed dotarciem do instrukcji “ret”, z powodu nadpisania jakichś zmiennych lokalnych nieprawidłowymi wartościami. Teraz, z aktywnym zabezpieczeniem, wykorzystanie tej techniki nie będzie możliwe.

Ta pierwsza część o której piszesz nazywa się stack canary / stack cookie btw. Ale są metody obejścia tego (nie zawsze, ale czasem są; bardzo ciekawe zresztą; to takie typowe pytanie na interview jak ktoś w CV ma exploitacje niskopoziomową :D).

---

Od stro­ny progra­mis­ty C/C++ po pros­tu trze­ba się sta­rać nie ro­bić błę­dów, a two­rząc bi­b­lio­te­ki/progra­my też my­ś­leć o tym, żeby wszys­tko by­ło se­cu­re-by-de­fa­ult (tj. de­fa­ul­to­we opcje/ek­spor­to­wa­ne fun­kcje by­ły be­zpie­cz­ne do uży­cia). A utru­d­nia­nie ex­plo­i­ta­cji / etc to do­me­na twó­r­ców kom­pila­to­rów / OSów / CPU.

Zre­sz­tą, le­piej użyć po pros­tu Rust/Go/itp ;)

No właśnie… zbudowałem własny projekt przełączania zadań w programie, oparty na składni języka C. Jestem w trakcie przepisywania go na Rust, którego w związku z tym się powoli uczę. Sprawdziłem: mimo użycia skoków i stosu w tym projekcie z włączonym CET nadal poprawnie działa; dlatego, że używam jawnie funkcji definiowanych w C. Rust ma składnię bardzo podobną do moich wcześniejszych oczekiwań, co realizowałem ułomnie makrami w C. Natomiast kiedy się nauczę wystarczająco Rusta, to dopiero będę mógł powiedzieć, czy zapewnia on wystarczające bezpieczeństwo programów.

Łatwo powiedzieć, żeby nie robić błędów… :)

ROP rest in peace z włączonym zabezpieczeniem od teraz.