ROP vs. DEP: a DEP napjai meg vannak számlálva?

Titkosítás, biztonság, privát szféra

A H Security egyik cikkében arról számol be, hogy a "JDuck" névre hallgató hacker nemrég felfedezett egy olyan speciálisan, rosszindulatúan összeállított PDF fájlt, amely a relatíve újnak számító Return Oriented Programming (ROP) technikát használja fel arra, hogy a kicselezze a Data Execution Prevention (DEP) névre hallgató biztonsági mechanizmust. A cikk szerint ez azt vetíti előre, hogy a DEP-pel biztosítani kívánt megbízható védelem napjai meg vannak számlálva.

Eredendően JDuck egy exploit-ot próbált illeszteni a MetaSploit Framework névre hallgató pentest keretrendszerhez. Amikor portolta az eredetileg Python-ban írt exploit-ot Ruby-ba, majd elkezdte tesztelni, azt figyelte meg, hogy az exploit problémamentesen működik az Adobe Reader 9.3 ellen is, annak ellenére, hogy az a verzió permanensen engedélyezi a DEP-et.

A további vizsgálatok kiderítették, hogy az exploit olyan technikát használ, amely megkerüli a DEP-et. "Nagyszerű, de miért kellene ezzel foglalkoznunk?" - olvasható a blogbejegyzésben. JDuck szerint azért, mert tudomása szerint ez az első olyan publikus exploit, amely ezt a technikát használja a permanens DEP megkerülésére.

A H Securtity cikke a témában itt.

( trey | 2010. 03. 20., szo – 20:57 )

Érdekes ez a videó. 42 vírusirtó nem talál a fondor PDF fájlban semmi kivetnivalót, miközben az pwnolja a rendszert.

--
trey @ gépház

Mondjuk felismeri a msfpayload-ot, amit beletett a csávó? Nem lehetetlen, mert azért egy-két termék képes erre. Az más kérdés, hogy a legtöbb AV termék elég béna ezeknek a payload-oknak a detektálásában. Pont ezt mutatta be a video.

Notably, F-SECURE, PANDA and WebWasher Gateway faired the best among the virus products in detecting these default payloads. AVG also did fairly well in detecting these threats. On average, about 10-11% of the Windows antivirus products detected the default msfpayload executables when written to disk.

Effectiveness of Antivirus in Detecting Metasploit Payloads

--
trey @ gépház

Szerintem nem hibás payloadot állított elő, hanem a jó payloadot utána még egyszer átfordította ROP stack kóddá, amire ebben a formában nyilván nagyon nehéz ráismerni. Különösen, hogy az összes ténylegesen végrehajtott utasítás valójában az acroread kódjából összeguberált függvénytöredékekből jön, a ROP esetén csak a stack pointereket állítgatja át úgy, hogy a megfelelő sorrendben a megfelelő kódtöredékek hajtódjanak végre.

Ha ez a helyzet, akkor az acroread memóriaképének ismerete nélkül esélytelen rájönni, hogy az injektált payload valójában mit is csinál.

(Persze mindezt inkább feltételezem, mint állítom az alapján, hogy az ROP témához kapcsolódva került elő ez a videó. Lehetséges, hogy ez az exploit konkrétan más technikát használva kerüli ki a DEP-t)
---
Internet Memetikai Tanszék

Nem ismerem a Comodo-t, de az minden kifelé irányuló kapcsolatot ellenőriz? Ha jól emlékszem, akkor a reverse shell-nek az a tulajdonsága, hogy nem a támadó próbál az áldozat gépéhez kapcsolódni, hanem az áldozat gépéről indul a kapcsolat a támadó gépe felé.

--
trey @ gépház

Ez beállítás kérdése, de alapesetben minden kapcsolatot (akár kifelé, akár befelé irányul) ellenőriz. Nem csak a Comodo, még egy csomó másik is.
Ha úgy állítod be kapsz ilyenkor egy ablakot, ami rákérdez, hogy mit is szeretnél.

Egyébként pont ez a feature az ami nekem marhára hiányzik Linux alól...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( Cobalt | 2010. 03. 20., szo – 22:18 )

Ugytunik, hogy a 64 bites W7 immunis ra 9.3 Reader mellet.

Esetleg valaki szakértő nem tudna kicsit bővebben nyilatkozni, hogy ebben a témában születtek-e már további eredmények?

Tehát pl. nem x86 platformokon, ahol alignoltak az utasítások (a cikkben a MIPS-et említik), is sikerült nekik megcsinálni?

Ez ellen a típusú támadás ellen tényleg nem lehet védelmet készíteni?

Üdv,
Gergely

Olyat találtam, hogy return oriented programming techinkával az egyik elterjedt ameriaki szavazógép Z80-as beágyazott CPU-ján (jéé, szavazógépben Z80-at használnak?!) futó kódba injektáltak mindenféle gonoszságot. Tették ezt annak ellenére, hogy a szerzők szerint biztonsági szempontból nagyon alaposan kivitelezett kóddal álltak szemben.
---
Internet Memetikai Tanszék

van mar sparc-ra, arm-re, z80-ra meg valami harvard architekturaju procira is ilyen. hadd ne keressem elo oket most, google-ben megtalalod oket az eredeti Shacham paper-re hivatkozassal (http://scholar.google.hu/scholar?cites=14337139712931477660).

> Ez ellen a típusú támadás ellen tényleg nem lehet védelmet készíteni?

ezt meg ki mondta? ;) a szamitastechnika hoskora ota ismert a problema, no nem biztonsagi szempontbol, hanem siman a hardware megbizhatosaga miatt (kozmikus sugarzas altal okozott memoriahiba pont olyan rossz tud lenni, mint amit egy exploit csinal). tessek olyan dolgok utan olvasgatni, mint Software Fault Isolation (SFI), en legutobb 40 evre visszamenoleg talaltam ra irasokat. az meg hogy miert nincs mondjuk ilyen gcc-ben vagy msvc-ben, a szokasos okra vezetheto vissza: dilettantizmus. nem ok nelkul szoktam mondani, hogy az ssp-re bo 10 evet kurtak el a joszakemberek ahelyett, hogy rendes CFI-t csinaltak volna inkabb (Control Flow Integrity, en is irtam rola 7-8 eve a PaX doksik kozott, nemsokara meg is irom talan ;), a MSR mar meg is csinalta a Gleipnir projektjuk kereteben).

( kecsa | 2010. 03. 21., v – 09:36 )

A ROP miben különbözik a return to LIBC-től fundamentálisan? Mert az utóbbi nem egy mai csirke. Ha hasonló a két dolog akkor a DEP tényleg csak ráolvasás...

ASLR ad valami védelmet (Linux esetekben csak azon lib hívások ellen, amit a kód eredetileg nem hívna).

Ha jól értelmezem, akkor egy elég komoly általánosítása ez a return to libc technikának. Az a nagy teljesítmény, hogy bebizonyította és technikát mutatott rá, hogy Turing-teljes nyelvet lehet alkotni ezzel a megközelítéssel, így gyakorlatilag bármilyen program átírható erre az eszközkészletre.

Tehát a DEP technikák tényleg semmit sem növelnek egy rendszer biztonságán. Ezelőtt a return-to-libc-t az eredeti formájában inkább kivételnek vagy speciális esetnek tekintették, amiről úgy gondolták, hogy viszonylag kevésféle esetben használható ki és más védelmi technikákkal (pl address space randomization) könnyen ki is védhető. A mostani eredmény rámutat, hogy ez nincs így.
---
Internet Memetikai Tanszék

Szép munka, köszi a linket, így már más. Linus szimpatikus volt, mikor a non-exec stack-et azonnal nem engedte be a mainline-ba mondván, hogy csak hamis biztonságérzetet ad. Kellenek az ilyen esetek (amiről a cikk szól), hogy a népek végre felfogják, hibás programokat nem lehet kijavítás nélkül biztonságossá tenni általános célú eszközökkel (majd a DEP/ASLR/PAX/akármi úgyis megfogja). Kanári talán véd ellene...

> Ha jól értelmezem, akkor egy elég komoly általánosítása ez a return to libc technikának.

a ret2libc mindig is tetszoleges letezo kod vegrehajtasat jelentette, soha nem korlatozodott szigoruan a libc kodjara (plane nem az eredeti utasitashatarokra). ez csak egy nev, ami a technikan ragadt, mert akik eloszor hasznaltak es beszeltek rola, azok speciel libc fuggvenyeket 'hivtak' meg egy exploit soran, na de az meg az elmult evezredben volt.

> Az a nagy teljesítmény, hogy bebizonyította és technikát mutatott rá, hogy Turing-teljes nyelvet lehet alkotni ezzel a megközelítéssel, így
> gyakorlatilag bármilyen program átírható erre az eszközkészletre.

nem, az a nagy teljesitmeny, hogy ezt a temat sikerult elsoznia egy konferencian, igy 2008AD (meg azota masok meg tobb helyen). mint irtam fentebb, az egesz problemakor evtizedek ota ismert, a megoldasokkal egyutt. a Turing-teljes dolgok meg teljesen erdektelenek a gyakorlati exploitalas soran, azert nem foglalkozott vele senki. szoval ez ilyen tipikus egyetemi kutatas, biztos kapott erte a tanszeken hatbaveregetest, de a szakma komolyabb resze azota is tekergeti a nyakat, hogy ez igy most mi akar lenni (nem beszelve arrol a teljes tudatlansagrol, ami a regota ismert megoldasokat illeti, de ezek a dolgozatok elfelejtenek roluk irni). februar ota pl. azert rohog mindenki rajtuk, mert 'felfedeztek', hogy nem csak 'ret' utasitassal lehet 'ret' viselkedest kivaltani. mashol ez egy kezdo asm programozonak szolo beugratos/elgondolkodtato feladat lenne...

> Tehát a DEP technikák tényleg semmit sem növelnek egy rendszer biztonságán. Ezelőtt a return-to-libc-t az eredeti formájában inkább kivételnek
> vagy speciális esetnek tekintették, amiről úgy gondolták, hogy viszonylag kevésféle esetben használható ki és más védelmi technikákkal (pl address
> space randomization) könnyen ki is védhető. A mostani eredmény rámutat, hogy ez nincs így.

talan el kene olvasni, hogy mirol szol a host intrusion prevention temakore, mi az, hogy exploit technika, mi az hogy, ezen technikak megakadalyozasa, stb. aztan kevesebb ilyen zoldseget irnal ;).

(nem beszelve arrol a teljes tudatlansagrol, ami a regota ismert megoldasokat illeti, de ezek a dolgozatok elfelejtenek roluk irni)
Mondjuk a related work részben elég sok említve van, azok közül, amiket felhozol. Nyilván nem tudom leellenőrizni, hogy az *összes* ott van-e.

az a nagy teljesitmeny, hogy ezt a temat sikerult elsoznia egy konferencian, igy 2008AD
Igen a világon már mindent feltaláltak, minden tudományos cikk valójában évtizedek óta ismert dolgok újraeladása, új eredmény nem születik sehol. Ezt én is tudom. Sőt ez az ÉN lemmám, mindjárt írok is cikket belőle. Ja, bocsánat erre már más rájött előttem. :)

Mutass már légyszíves egy olyan cikket CS témakörben, amire ez többé-kevésbe nem húzható rá! Dijkstra és hasonló nagy öregekkel előjönni nem ér. :)

talan el kene olvasni, hogy mirol szol a host intrusion prevention temakore
Nem konkrétan ez a kutatási területem. Azért ahhoz, hogy kellő mélységben képben legyek, ahhoz legalább a kb 100 legfontosabb cikket (azért 100, mert abban szubjektív választás esetén is esélyes, hogy benne lesz az a 20 ami tényleg fontos) ismernem kéne a témakörben és bevallom van nekem 100 másik cikk is, amivel foglalkoznom kéne.

Most elolvastam amit írtak, megnéztem a related worköt, ránézésre kb. jónak láttam. Nem állították, hogy megoldották a világegyenletet, meglévő eredményekhez képest fogalmaztak meg új állítást. Nyilván, ha nekem kéne elbírálnom, akkor erre több időt kéne szánni. De nem nekem kell elbírálnom, mert nem vagyok security témájú konferencia PC-jében. Szerencsére... nem is szeretnék ilyenben lenni.

aztan kevesebb ilyen zoldseget irnal
Ajjaj, attól félek beletapostam valakinek az erogén zónájába... :)

Most a W^X-ről van konkrétabban szó és igen, sokáig bagatellizálta az ipar, hogy valójában ezek mennyire keveset érnek. Nyilván a CPU gyártók marketingje miatt, ugye "majd jön az XD bit meg LaGrande technológia és minden biztonsági problémát megold, cseréld le a processzorodat sebtibe' olyanra amelyikben ez van". Ez volt az állítás. Ez zöldség?

Ha abból a szempontból nézzük a turing teljességet, hogy erre hivatkozva könnyebb meggyőzni az ipart, hogy ne tekintsék különösebben értékesnek a W^X megoldásokat, akkor is teljesen értéktelen akadémiai hulladék? Szerintem nem ez volt az egyetlen ilyen "eredmény", ami gyakorlati szempontból nem mondott sok újat, de mégis szükség volt rá, hogy komolyan vegyenek egy problémát.

Én elmondtam azt, hogy mit olvastam ki a cikkből. Szerinted meg a cikk (illetve a prezentációjuk, ha már azt linkeltem be) hülyeségeket állít. Sajnos véges idő áll rendelkezésére mindenkinek ezt eldönteni, hogy így van-e vagy sem. Mások ennyit sem tesznek meg.
---
Internet Memetikai Tanszék

> Mondjuk a related work részben elég sok említve van, azok közül, amiket felhozol. Nyilván nem tudom leellenőrizni, hogy az *összes* ott van-e.

ezt melyik dolgozatra irod? mert konkretan a legelsoben, amit Shacham irt, egyreszt nincs olyan szekcio, hogy related work, masreszt veletlenul sem ir egyetlenegy vedelemrol szolo munkarol. a kesobb jovok is csak immel-ammal, leragadva egy 93-as dolgozatnal, pedig meg annal is sokkal korabbi a tema.

> Igen a világon már mindent feltaláltak,[...]

messze nem. de speciel a ROP elleni vedelmet mar igen. meg nekem is sikerult 8 evvel ezelott ;).

> Mutass már légyszíves egy olyan cikket CS témakörben, amire ez többé-kevésbe nem húzható rá!

mondok temat: kernel onvedelem (ahol a vedelmi mechanizmus az exploitalt koddal azonos privilegium szinten fut). ha te talalsz ra megoldast (marmint hogy valaki mar megoldotta), akkor en roppant kivancsi leszek ra.

> Nem állították, hogy megoldották a világegyenletet, meglévő eredményekhez képest fogalmaztak meg új állítást.

az a baj, hogy semmi sem volt uj benne, legalabbis a szakmabelieknek (azaz itt a hackereknek. egy konferenciara jo volt, mert gondolom a biralok meg annyit se ertettek a temahoz, mint a dolgozat iroja). mellesleg az adott uriember nem eloszor kovette el ezt a dolgot, meg valamikor 2004 tajan irt egy hasonlo kaliberu dolgozatot az ASLR-rol.

> Most a W^X-ről van konkrétabban szó és igen, sokáig bagatellizálta az ipar, hogy valójában ezek mennyire keveset érnek.[...]

latom meg mindig nem erted. nem bagatellizaltak el semmit, mert ezek a dolgok nem keveset ernek, hanem sokat. erre mondtam, hogy utana kene nezni annak, hogy mirol szol az egesz host intrusion prevention tema, ill. konkretabban ezek az exploit technikak ellen kifejlesztett vedelmek. legalabb annyit tegyel meg, hogy elolvasod a PaX doksikat, abbol kiderul a strategia, amit en kovetek idestova 10 eve (meg azota mar sokan masok is).

Ú b+, jó ok, igaz ezt a google scholaron elnéztem, a linkelt prezi nem ahhoz tartozik, amelyikekbe belolvastam, annak nincs is szerzői között Shacham. A preziben van pár related work felsorolva meg abstract alapján is kerestem néhány témába vágó cikknek utána, aztán nem tűnt fel, hogy nem tartozik össze. Szóval akkor most tényleg hülye voltam. :(

Te akkor erről beszélsz? http://cseweb.ucsd.edu/~hovav/dist/rop.pdf

A beszúrt ábrák és kódrészletek alapján talán ez tartozhat a prezentációhoz.

Mondjuk érdekes, ez formáját tekintve inkább folyóiratcikk, mint konferenciacikk. Azzal is teljesen egyetértek, hogy related work nélküli cikk az mindeképpen gáz, akármilyen témakörben. Egy folyóiratcikknél még azt sem lehet mondani, hogy terjedelmi korlátok miatt hivatkozik kevés korábbi munkára. Értelmes konferenciára/folyóiratra így nem megy be, ehhez nem kell hozzáértőnek sem lenni, hogy a bíráló rejectet szavazzon rá. Mondjuk egyáltalán megjelent ez valahol? A csávó saját honlapján kívül?

messze nem. de speciel a ROP elleni vedelmet mar igen. meg nekem is sikerult 8 evvel ezelott ;)
Természetesen ez egy sarkított állítás, arra, hogy az akadémiai világban manapság mennyire gyér a tényleges új eredmény és mennyire sok a régi eredmények újraprezentálása.

ha te talalsz ra megoldast (marmint hogy valaki mar megoldotta), akkor en roppant kivancsi leszek ra.
Ha valaki talál rá ténylegesen hatásos megoldást akkor az lesz kb az 1db kivétel abban az évben a publikált cikkek közül. Tényleg elég nehéz feladatnak hangzik.

ezek a dolgok nem keveset ernek, hanem sokat.
Na akkor most kezdek kíváncsi lenni, bár megmondom őszintén nem sok energiám van arra, hogy mélységében felfogjam minden implikációját. Ahhoz, hogy a W^X érjen bármit is, ahhoz az kell, hogy - akár implicit módon - ne tudjak interpretert meghívni a végrehajtható memórialapok valamelyikén, akár a stack pointerek manipulálásával. Olyan van, hogy stack base randomization, viszont nem teljesen világos számomra, hogy ez elvileg képes-e arra, hogy megakadályozzon egy ROP/return-to-libc típusú támadást. Az a baj, hogy ehhez most elő kéne ásnom a stack layoutot, hogy lássam, hogy egy stack overflow pontosan hogyan is néz ki, melyik irányba tudok felülírni vele. Úgy rémlik, hogy ez ellen az szokott az ellenpélda lenni, hogy NOP-okkal kell felülírni, akkor rá lehet csúszni a randomizálással elolt helyre is. De ezt mondjuk régebbi emlékeim alapján mondom, nem biztos, hogy ez a technika a stackre adaptálható. Tény, hogy így azért macerásabb a feladat, de nem vagyok meggyőződve róla, hogy lehetetlen.

Ja még hozzátenném, hogy eredetileg a Shacham prezentációjában azért tartottam lényeges részletnek a Turing-teljességet, mert így biztosan lehet implementálni keresőalgoritmusokat benne, amivel van esély egy randomizált memóriakép kivédésére is. Viszont, ha a stack base randomization eleve megfogja, akkor nyilván hibás ez a logika.
---
Internet Memetikai Tanszék

nem az volt az elso, hanem ez: http://scholar.google.hu/scholar?cluster=134264362749273001 (ez volt a CCS07-en, ami egy 'elit' konferencia, l. http://faculty.cs.tamu.edu/guofei/sec_conf_stat.htm). de mellesleg az altalad felhozott dolgozatban is csak egy arva szekciocska van Mitigations neven es *semmi* nem szerepel benne az igazi vedelmekrol, meg csak a korabban emlitett 93-as Wahbe/Lucco SFI munka sem (http://www.google.com/search?q=wahbe+lucco+sfi).

> Ahhoz, hogy a W^X érjen bármit is, ahhoz az kell, hogy - akár implicit módon - ne tudjak interpretert meghívni a végrehajtható
> memórialapok valamelyikén, akár a stack pointerek manipulálásával.

na itt lesz a kutya elasva, mert nem errol szol ;). az intrusion prevention vagy konkretabban az exploit mitigation celja, hogy exploit technikakat tegyen hasznalhatatlanna, es nem az, hogy hibakat tegyen nem kihasznalhatova. ez nagyon fontos kulonbseg, ez a kulcsgondolat es tobb implicit allitast is magaban foglal:

1. egy hibat tobbfajta modon is ki lehet hasznalni (az en kategorizalasom kb. a legaltalanosabb, de meg gyakorlatban ertelmes mod, megtalalod a PaX doksi oldalan)
2. nem minden exploit mod ad ekvivalens iranyitast a megtamadott rendszer felett
3. kulonbozo exploit technikak kulonbozo feltetelek mellett lehetsegesek csak

miert erdekes ez a megkozelites? mert ha egy rendszer garantalni tudja, hogy milyen exploit technikak mukodhetnek csak a rendszerben levo hibak ellen, akkor ezt maris be lehet epiteni egy rizikoelemzesbe (ti. csokken a riziko) es az ilyentol szeretnek boldogok lenni a menedzser tipusu emberkek. nem mellesleg a 2. es 3. pontok miatt effektive is no a rendszer biztonsaga, hiszen bizonyos jol korulirhato dolgokat nem lehet megtenni akkor sem, ha egy tamado pl. tetszoleges memoriat irhat/olvashat egy megtamadott processzben (ezen a teruleten ez az 'ultimate threat model', a gyakorlatban a hibak tipikusan kevesebb hatalmat adnak az exploit iro kezebe, de azert mi szeretunk a legrosszabb esetre felkeszulni).

akkor visszaterve arra, amit irtal. a W^X celja a futasideju kodgeneralas kontrollja (konkretan megakadalyozasa minden programban, aminek ez nem letszukseglete). ezt meg lehet csinalni nem megkerulheto modon (pl. PaX, de manapsag mar SElinux policyval is ki lehet fejezni, ha valakinek agyu kell a verebre ;). mi marad az exploit iroknak? termeszetesen a tobbi exploit technika: meglevo kod vegrehajtatasa, aminek ket alkategoriajat celszeru megkulonboztetni attol fuggoen, hogy ezt a meglevo kodot az eredeti programozo altal szandekolt sorrendben hajtatjuk vegre (itt logikai hibakat okozunk a programban, l. http://www.google.com/search?q=Non-Control-Data+Attacks+Are+Realistic+T…) vagy sem (ez a ret2libc, ROP, stb). csakhogy itt mar nem adjak a menyasszonyt olyan olcson, ezen technikak ui. nem altalanosak, szukseges az adott program pontos ismerete (a shellkod vegrehajtasnal nem kell semmit se ismerni, csak a tenyt, hogy valahol felulirunk pl. egy visszateresi cimet, aztan hadd szoljon). a ROP-nal ugye pontos cimek ismerete szukseges, ill. az a teny, hogy el lehet teriteni legalabb egy fuggveny pointert. amivel a megoldast is megmondtam (ASLR ill. fv ptr-ek ellenorzese dereferencia elott). ezek utan mar 'csak' a tiszta adatmodositasra epulo technika marad, ez meg aztan tenyleg program fuggo, es tipikusan csak azt lehet vele elerni, amire az adott program amugy is kepes lenne, tehat nem privilege elevation-re jo, hanem 'csak' privilege abuse-ra, amitol persze meg fontos, de kisebb rizikot jelenthet egy adott helyzetben.

> Ja még hozzátenném, hogy eredetileg a Shacham prezentációjában azért tartottam lényeges részletnek a Turing-teljességet,
> mert így biztosan lehet implementálni keresőalgoritmusokat benne, amivel van esély egy randomizált memóriakép kivédésére is.

azt ugye erted, hogy ezt a randomizalt memoriaterkepet a priori ismerni kell ahhoz, hogy egy ilyen ROP keresoalgoritmust (vagy barmit) 'futtatni' tudj? ;)

Köszi az összefoglalást, nekem hasznos volt.

Az ASLR-t ha jól értem a PaX megcsinálja. A függvénypointer ellenőrzést is, vagy ehhez szükség van más eszközökre?

Egy másik kérdésem is lenne, kicsit offtopic: az egész W^X megoldásnak, ha jól értem, a legnagyobb ellenségei maguk az alkalmazások, konkrétan azok, amelyek eleve úgy vannak tervezve, hogy runtime kódgenerálást csinálnak a processzen belül. Ilyenek a különböző JIT-et használó runtime-ok (pl. java), de pl. Androidban a rajzoláshoz is generálnak futásidőben kódrészeket.
Szerinted biztonsági szempontból csökkenthetők lennének az ezek által okozott kockázatok, ha a kódgenerálás külön worker processzben történne, és a generált kódot végrehajtó processzben már nem írhatók ezek a lapok? Nyilván a legnyilvánvalóbb támadási vektor ellen nem véd: átadod a runtime-nak a támadásra használni kívánt kódot, hogy JIT-elje le, de talán magában a runtime-ban található hibák kihasználhatóságát csökkentené.

Üdv,
Gergely

> Az ASLR-t ha jól értem a PaX megcsinálja.

igen (onnan jon a rovidites maga is).

> A függvénypointer ellenőrzést is, vagy ehhez szükség van más eszközökre?

nem, ezt kernelbol nem lehet megcsinalni, ehhez a toolchain (leginkabb fordito) modositasa szukseges, meg termeszetesen a programok ujraforditasa.

> az egész W^X megoldásnak, ha jól értem, a legnagyobb ellenségei maguk az alkalmazások, konkrétan azok, amelyek eleve úgy vannak tervezve,
> hogy runtime kódgenerálást csinálnak a processzen belül.

igy van, bar azert ellensegnek hivni oket kicsit eros ;), inkabb ugy fogalmaznek, hogy ez a fajta vedelem (es a vele jaro garanciak) nem alkalmazhatok rajuk (aminek persze nem orul senki se, de ez van, ill. mas megoldasokat kell keresni).

> Szerinted biztonsági szempontból csökkenthetők lennének az ezek által okozott kockázatok, ha a kódgenerálás külön worker processzben történne,
> és a generált kódot végrehajtó processzben már nem írhatók ezek a lapok?

attol fugg, mi a threat model, azaz mitol felsz ;). ha csak az erdekel, hogy egy userland processz ne matasson egy masikban, akkor a userland processzekbe valo szeparacio teljesen jo. de a gyakorlatban ehhez kell egy 'tokeletes' kernel is, kulonben az exploitalt processz (vagyis a tamado) elso dolga lesz, hogy egy kernel hiban keresztul kitorjon a userland processz kore epitett vedelembol. tehat a gyakorlatban kell rendes kernel onvedelem (megoldatlan problema) es/vagy olyan vedelem a JIT forditoba, ami garantaltan megakadalyozza nem kivant kodok generalasat (ez is megoldatlan problema).

> Nyilván a legnyilvánvalóbb támadási vektor ellen nem véd: átadod a runtime-nak a támadásra használni kívánt kódot, hogy JIT-elje le, de talán
> magában a runtime-ban található hibák kihasználhatóságát csökkentené.

igazabol a JIT forditok problemaja azonos a normal forditasnal meglevovel (amire szinten nincs megoldas): hogyan lehet detektalni nem kivant (forras)kodot. ez a megallasi problemara vezet, tehat altalanosan nem megoldhato. amit szerintem a gyakorlatban el lehet erni (marmint meg talan elfogadhato eroforras felhasznalassal) az az, hogy (erosen) korlatozzuk a lefordithato programok halmazat (whitelist API-kra, stb) ill. ezt a korlatozo logikat megvalosito JIT engine kodot (ill. azt is, amit general) megvedjuk, amennyire csak lehet (minimum ret2libc elleni vedelem, meg egyebek). ezek utan valamennyi garanciank lesz arra nezve, hogy a generalt kod mit (nem) csinalhat. az mas kerdes, hogy egy adott felhasznalasra ez a garancia erdemi elorelepes lesz-e vagy sem, majd kiderul, ha egyaltalan sikerul valamit ebbol megvalositani.