Múlt héten a Black Hat USA konferencián kiosztották az első BlueHat Prize díjait. A pályázat célja olyan új technológiák kidolgozása volt, melyek hatékony védelmet biztosítanak napjaink exploitjaiban használt ROP láncok ellen, esetleg végérvényesen megakadályozzák a kódújrahasznosításon alapuló támadásokat. 

A 200.000 dolláros fődíjat végül Vasilis Pappas kBouncer megoldásának ítélték oda, Ivan Fratic ROPGuardja az 50.000 dollárt érő második helyet, Jared DeMott /ROP koncepciója pedig a 10.000 dolláros harmadik helyet szerezte meg. Az SRD rövid áttekintést ad a győztes pályamunkákból, nézzük milyen újítások várhatóak a Microsoftnál a ROP-ellenes technológiák terén (a posztban megfigyelhető egy ritka érdekesség: Technetes link a Phrack.org-ra):

/ROP

DeMott egy fordítás idejű megoldást javasolt: elképzelése szerint a fordító létrehozhatna egy olyan adatstruktúrát a futtatható állományban, ami tartalmazza azokat a címeket, ahová a program futása egy RET utasítás után visszatérhet. A betöltő ezeket a listákat felolvasná, majd a RET utasításokra töréspontokat helyezne, melyek kezelésekor az operációs rendszer eldöntené, hogy a visszatérési cím engedélyezett-e, és folytatható-e a program futása.

A megoldás nyilvánvaló problémája az erőforrásigény, a visszatérési címek ellenőrzéséhez ugyanis vállalhatatlanul sok processzoridő és/vagy memória lenne szükséges (adatstruktúrától függően), ezen kívül a ROP gadgetek megfelelő összeválogatásával, illetve más ugró utasítások használatával az ellenőrzés megkerülhető lehet.

ROPGuard

Ivan Fratic munkája egy sor már ismert módszert, és több saját újítást is összefoglalóan tartalmazott a ROP láncok által gyakran hívott API-k (pl. VirtualAlloc, LoadLibraryA, stb.) megerősítésére. Az elképzelés szerint ezeket az API-kat meg lehetne patkolni néhány plusz ellenőrzéssel, melyek elfogadható teljesítmény veszteséggel észlelnék ha nem megszokott helyről/módon hívják őket. Néhány példa ezek közül:

• Stack pointer értékének ellenőrzése a stack pivoting detektálására.
• A kritikus függvények visszatérési címeinek ellenőrzése: ha a címet nem előzi meg call, vagy nem futtathatóan volt mappelve, megállunk
• Stack frame-ek ellenőrzése az előző két kritérium alapján
• Futásszimuláció annak eldöntésére, hogy a kritikus függvény visszatérése után az első két feltétel teljesül-e minden visszatérésre

Hasonló megoldásokat a Windows 8 előzetesében már láttunk (elesni), Fratic munkája azonban annyira tetszett a Microsoft mérnökeinek, hogy a megoldásokat már be is építették az EMET 3.5 előzetes kiadásába (a cucc még nem javasolt éles üzembe, de a Microsoft szeretné, ha minél többen elkezdenének kísérletezgetni vele, a kompatibilitási problémákat feltárandó). 

Azt ugyanakkor a Microsoft szakértői is megjegyzik, hogy az egészséges ár/érték (biztonság/teljesítmény) fenntartása mellett valószínűleg maradnak majd olyan, kritikus funkcionalitáshoz vezető útvonalak, melyeken keresztül az meglévő láncokat az új ellenőrzésekhez lehet igazítani, de más kerülőutak - pl. ugrás az ellenőrző kód után - is elképzelhetőek lehetnek.

kBouncer

Vasilis Pappas győztes pályamunkája az Intel processzorok Last Branch Recording (Intel doksi itt, 19.4-19.10-es fejezetek) lehetőségét kihasználva ellenőrzi, hogy a kritikus API hívásokhoz vezető RET utasítások CALL-ok utáni címre tértek-e vissza (a pályázat hasonló ellenőrzést javasolt a rendszerhívások szintjén, de erre prototipus a Windows kernel korlátozásai miatt nem volt adható). 

A probléma itt leginkább a kompatibilitás, valamint az, hogy az LBR csak korlátozott számú ugrást tud lekövetni. Ezen túl az összes potenciálisan kritikus kódútvonal lefedése ismét jelentős teljesítményveszteséget okozna, így a támadók előbb-utóbb találnának kihasználható ösvényeket.

(4:20 ;)

Univerzális megoldás tehát nem született a ROP problémára, de a fenti megerősítések biztosan kiültetnek majd néhány izzadságcseppett a támadók homlokára (ha egyszer bekerülnek az alap Windows terjesztésekbe). Addig is érdemes - a progresszív védelem vagy a gyakorlás miatt - folyamatosan figyelni és tesztelni az EMET újításait valamint tanulmányozni a Phrack remek cikkeit.

Úgy tűnik, a Microsoft lát potenciált pályázatban, következő BlueHat kérdését már elkezdték válogatni (minden jó ötlet 5000 dollárt ért a BlackHat-en), ha megjön a kiírás, posztolok mindenképp!