Exploit hatástalanítási technikák

Igen, s épp a Neumann arch. a hibás.

Ok, de mi védi meg az egyes szegmenseket attól, hogy ne lapold át őket, ill. másik program ne használja őket közvetlen memória-eléréssel?

Az utolsó mondatod kérdése alapján a határozott kijelentésed s a kioktató szöveged kicsit erősnek látszik....

Talán még Neumann mondta, hogy legyen a kód és az adat egy helyen, nem? :)

Jol hangzik...

Ezekbol a technikakbol mennyit lehet jelenleg a Linux kernelben megtalalni? Esetleg valami patch-csel?

Peldaul ProPolice sok linux distroban megtalalható, például a gentooban. A privilege revocation/separation pedig attól függ, hogy veszi-e a fáradtságot egy programozo, hogy igy írja meg a programját. Termeszetesen OpenBSD ben a "regi" kódokat is át kellet alakítani, de ezt a fejlesztők végezték el. A stack-based buffer overwflowok ellen van linuxra PaX. Azt hogy az OpenBSD ben eszközölt address space tweakeket alkamazza-e grsec, azt nem tudom de nem is nagyon érdekel ;-)

A Tinysofa pl. defaultban SSP-s GCC-vel fordít mindent.

A ProPolice a fogkeremben meg a mehkaptarban is megvan mar, nem? ;-)

Szoftveresen kijavítani egy hibás architektúrát ...

Mindig is jó szórakozás volt, s még lesz is :)

a 'vanilla' kernelben kb semmi nincs, viszont vannak speci disztribuciok, ahol van minden ill. meg tobb. a ket legfontosabb az Adamantix (http://www.adamantix.org) es a Hardened Gentoo (http://www.gentoo.org/proj/en/hardened/). a kernel oldalon mindkettoben van PaX + valamilyen mandatory access control rendszer (grsecurity, RSBAC ill. SElinux), a userland-ben pedig SSP ill. egyeb dolgok, amik kb. azt csinaljak, mint az OpenBSD, csak nehol jobban (pl. a RELRO/BIND_NOW kezeles hatekonyabb, nem is beszelve a PaX-rol).

a veremtulcsordulas csak egy pici reszhalmaza azon bugoknak, amik elleni tamadasokra a PaX keszult (ditto az OpenBSD W^X-re). amugy meg kar a szavakkal jatszani, a grsec nem az OpenBSD-bol vette az 'address space tweak'-eket, hanem forditva, az OpenBSD fejlesztok csinaltak meg a PaX egy reszet (tobb-kevesebb sikerrel) az evek folyaman. ha nem hiszed, nezd meg, hogy ki mikor csinalt meg egy feature-t. pl. randomizalas (mindenfele) 3 eve van PaX-ban, szemben az OpenBSD 1-2 evevel (attol fuggoen, hogy melyik memoriateruletet nezzuk). non-exec memorialapok ugyebar lassan 4 eve vannak PaX-ban, az OpenBSD-ben meg alig 2 eve (i386-on 1 eve se).

ha nagyon egetni akarod magad es az OpenBSD-t, akkor hajra, ma eppen raerek ;-).

Ezeken a disztribuciokon viszont nem fut az Oracle, SAP es a tobbi "fontos" alkalmazas (vagy ha fut is, akkor sem supported), amikkel a Linuxosok oly sokszor vagdalkoznak a BSD ellen... ;)

bar nem tudom, hogy kerul a csizma az asztalra, de azert erdekelne, hogy melyik BSD-n fut *es* tamogatott az Oracle, SAP es a tobbi "fontos" alkalmazas ;-). szoval inkabb maradjunk a topicnal... ;-)

Epp azt irtam, hogy lenyegeben nem jobb a helyzet ezeknel a disztribucioknal sem amelyeket emlitettel, hisz azokon se futnak ezek az alkalmazasok. Hiaba lenne biztonsagos, ha egybol nem lehet semmivel sem tobbre hasznalni oket, mint a BSD-ket. ;D

Jelen esetben nem az architektúra a hibás, hanem a szoftver...

Hibás szoftver semilyen architektúrán sem fut jól. :P

:(

ja, azt nem tom, hogy a fent nevezettekbol mi fut rajtuk, olyan embereket viszont ismerek, akik kbzo redhat szervereken nem a redhat kernelet futtatjak, hanem grsec-t (es aztan jonnek hozzam, hogy az ilyen-olyan ***** a redhat glibc-ben miert nem megy a PaX-szal, lehet keresgelni a redhat bugzillaban a reszletek utan). azt persze nem tudom, hogy a redhat mennyire szereti az ilyet tamogatni (gondolom sehogy), bar ez vegulis erdektelen, ha az adott ugyfelnek ugyis fontosabb a biztonsag, mint a redhat tamogatasa.

amugy a 'hardened' disztribucioknak nem az a lenyege, hogy tobbre lehessen oket hasznalni, mint mast (legyen az mas linux vagy akar BSD), hanem az, hogy az egesz biztonsagosabb legyen (ami a gyakorlatban ugy jelent sporolast, hogy nem kell hanyatt-homlok frissiteni a ceg osszes szerveret, ha napvilagra kerul egy bug, vagy ami meg rosszabb, exploit).

Sajnos a tapasztalat az, hogy a cegeknek fontosabb a tamogatas, mint a biztonsag... :(

Az architektúra a hibás, mert egy fizikai területen van a stack, data és code szegmens. Ezt aztán patchelheted sw-ből, mindig lesz más megoldás.

ehem, mit jelent az, hogy 'egy fizikai teruleten van...'?

A Windows "memórivédelméről" mit gondolsz ?

Akkor legyszives mutass hogy az mit is mikor masolt le OpenBSD? Kodreszletekre vagyok kivancsi, nem szavakra.

azt, hogy nagyon jo lepes a helyes iranyba, es oszinten szolva, meglepo egy MS kaliberu cegtol. az mas kerdes, hogy a windows mas problemai (jo, legyen 'feature') miatt az o memoriavedelmuk is megkerulheto, de ehhez 'ret2libc' tipusu tamadas kell (tavaly osszel volt a bugtraq-en egy exploit windows ala, ami demonstralta ezt).

szerinted hanyszor irtam le azt a szot, hogy 'masolt'? ;-) ugy latszik, egyedul is kivaloan egeted magad, meg csak segitseg se kell hozza...csak hajra, hosszu meg a nap.

ha erdekel a windows fejlodese, akkor erdemes ezt is figyelemmel kiserni: http://research.microsoft.com/research/sv/gleipnir/

jo mindegy akkor. nem vagyok erre kivancsi. azt hiszel amit akarsz, de van jobb dolgom is.

amit leirtam, az nem hit hanem tenyek kerdese, ez ezen nem valtoztat az sem, ha neked tortenetesen nem tetszik. ha tudsz mas konkret tenyeket (nem puszta szavakat), akkor mutass rajuk.

Pont ezt kertem toled is. Mutasd be a tenyeket.

PaX, non-exec lapok majdnem 4 eve: http://marc.theaimsgroup.com/?l=bugtraq&m=97288542204811&w=2

ASLR (randomizalas), erre csak kod van, eloszor a 2.4.6-ra jelent meg, 2001.07.23-an (itt meg csak mmap() volt), 2001.08.10-tol pedig volt verem is. ha kell a kod, felrakom vhova, csak szolj (vagy levadaszod a 2001 szeptemberi grsec 1.8-at, abban is bent volt mar).

OpenBSD: http://www.openbsd.org/34.html, 2003.11.01. innentol van W^X/i386 ill. library randomizalas. a veremrol nem sokat talalni, a cvs szerint 2002 februartol engedelyeztek, szoval elvileg a 2002 majusi 3.1-ben mar volt, de ezt most nem tudom letesztelni.

akkor ugye most jonnek a te tenyeid?

Igy van. Az OpenBSD fejlesztok az eg adta vilagon semmit nem tudtak aPaX rol meg arrol se hogy letezik. Attol meg hogy CVS be mikor commitelnek valamit az nem azt jelenti, hogy a maga a kod mar nem letezik evek ota. En nem azt szeretnem bebizonyitani, hogy ki kirol koppintott.

ezez ures szavak, hol vannak itt a tenyek??? de hogy mennyire beegtel mar megint, nezd meg ezt: http://marc.theaimsgroup.com/?l=openbsd-tech&m=97416533704634&w=2 . ez ugye elegge OpenBSD levlista, nem? latod rajta a datumot is? aztan nezzuk Theo kedvenc peldajat, amire o maga hivatkozott 1 eve a bugtraq-en is: http://stackghost.cerias.purdue.edu/stackghost/node32.html . latod azon is a datumot? szoval ki es mirol nem tudott pontosan?

Najó, de kinek az apukája az erősebb? ;D

Az enyém, mert barátaimmal már akkor 2Pac-ot hallgattunk, mikor Thuglife még oviba járt :-) Megvolt az összes album még a halála előtt, utána szoktunk le róla, hogy megvegyük vagy nyilvánosan hallgassuk. Szóval, mi bármikor lenyomunk egy whiggert :-) mert nem divatosak vagyunk :-) De, izé, hogyan is jön ez a témához?

A többi archtektúránál nem tudom mi a helyzet, de az x86 architektúrák az Intel 386-osa óta teljeskörű hardveres támogatást adnak a memóriaterületek szegmentáláshoz és hozzáférési jogok kezeléséhez (írható, olvasható , futtatható).
Az egy másik kérdés, hogy a ma ismert operációs rendszerek ezt nem használják ki, pedig a mai teljesítmények mellett csak pár hónapos visszaesést jelentene teljeítményben akár 10-20% teljesítményveszteség.

PaX kihasznalja (ugy hivjak, hogy SEGMEXEC, van rola doksi), es maga a szegmentalas semmi merheto teljesitmenyvesztest nem okoz(hat), a tamogato logika (vma mirroring) olyan 2% korulit max (de ez is csak akkor latszik, ha sok a fork/execve).

az x86 architektúrák az Intel 386-osa óta teljeskörű hardveres támogatást adnak a memóriaterületek szegmentáláshozés hozzáférési jogok kezeléséhez (írható, olvasható , futtatható).

Hmm, biztos ez? (;

[Akkor vajon miért csinálnak a fejlesztők mindenféle haszontalan dolgot, mint pl. PaX, OBSD W^X, MIngo exec shieldje, az openwall non executable stack pages hackje, ha ezt már a 386 óta hardware támogatja?!]

nevetseges.

Igen tudom, bár nem processzenként különböző szegmenseket, hanem két nagy szegmens (1,5G-1,5G) használ, ha jól tudom, feltehetőleg ennek köszönhető, hogy kicsi a teljesítményveszteség.


Amúgy én is használom a grsec-et (így PaX-ot is), köszönet a fejlesztéséért.

biztos ;-). vedett modban nem lehet akarmilyen szelektort tolteni a kodszegmens regiszterbe, annak kod tipusu szegmensre kell mutatni (adatszegmens regiszterben mehet kod es adat szegmens szelektor is). persze mindez akkor er igazan valamit, ha a kod/adat szegmensek nem atlapolo memoriatartomanyokat definialnak. praktikus okok miatt azonban szinte az osszes vedett modban futo oprendszer teljesen atlapolodo szegmenseket hasznal, tobbnyire 'flat model'-nek hivjak, ahol mindket fajta szegmens 0 bazisu 4GB hatarral. ez azert praktikus, mert igy egy pointer (logikai cim) maradhat 32 bit, nem kell hozza tudni, hogy melyik szegmensben ervenyes, mert mindegy. hatulutoje persze, hogy ezzel kvazi elveszik a szegmentalas ertelme (marmint a memoria vedelmi celokra). szoval az altalad emlegetett haszontalan megoldasok semmi mast nem csinalnak, mint megprobalnak kolonbozo modon ujra hasznot huzni a szegmentalasbol.

Azért csinálják, mert a kernelfejlesztők nem csinálják :))

Akkor viszont keverek valamit... Mégpedig a 64 bites Athlonok [meg a hasonló Intel processzorok] no-execute page-protection (NX) feature-jével. Ez miben más/több mint a nem futtatható szegmens?

[Az előző postban a haszontalant természetesen idézőjelben értettem]

Klikkelgetek azért közben bőszen:

"Traditionally page protection is implemented by using the features of the

CPU Memory Management Unit. Unfortunately IA-32 lacks the hardware support

for execution protection, i.e., it is not possible to directly mark a page

as executable/non-executable in the paging related structures (the page

directory (pde) and table entries (pte))."

Ezzel kevertem az előbb azt, amit Xanco mondott. És ezt oldja meg az NX, ugye?

igy van, az NX feature nem mas mint egy uj bit a page table entry-ben (uj olyan ertelemben, hogy annak a bitnek eddig semmi szerepe nem volt), ami az adott memorialap vegrehajthatosagat szabalyozza, hasonloan ahozz, ahogy pl. a read/write bit meg az irhatosagot.

Nem az architektura a hibas. Tudod, tamogatott a szegmentalas, de ezt valamilyen okbol a fejlesztok nem hasznaljak. Egyebkent itt mit ertesz az alatt, h "egy fizikai területen van a stack, data és code szegmens."?