Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

BlueHat Prize eredmények

2012.07.30. 17:20 | buherator | Szólj hozzá!

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!

Címkék: microsoft blackhat phrack rop bluehat Ivan Fratic jared demott vasilis pappas

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.