virtual address space randomizálás

Kernel

Arjan van de Ven egy olyan patchet küldött az LKML-re, amely randomizálja a processzek virtuális címterületét. A patch célja, hogy védelmet nyújtson a kernelhez készült puffer túlcsordulásos exploitok ellen. Az infrastruktúra még nincs teljesen kész, jelenleg éppen csak megkezdődött a munka. A patch az exec-shield-ből született.

A patch nem randomizálja a brk() területet és nem támogatja a PIE binárisokat. E funkciók a következő verziókban mutatkoznak majd be.A patch beküldése szokás szerint flame-et váltott ki. A flame oka, hogy a PaX ASLR funkciója hasonló ehhez a megoldáshoz annyi különbséggel, hogy egyesek szerint hatékonyabb.

Kritika érte a patchset-et több ponton is. A kritikusok szerint a 64Kb-nyi randomizálás kevés (a PaX 256MB-tal teszi ezt), és hiányzik a brk() által kezelt terület randomizálása is (a PaX ezt is tudja). Arjan szerint az exec-shield randomizálja a brk()-t, de ebben a patchben ez a funkció nincs benne, mert a használata veszélyes lehet a programok működése szempontjából (bizonyos programok nem, vagy rosszul működnének).

Az egyik hozzászóló szerint a 64Kb randomizálást triviális dolog kikerülni. Szerinte ez a megoldás legalább akkora vicc, mint az OpenBSD stackgap megoldása.

Mint válaszában Arjan írta, a 64Kb valóban kicsit, de ezt csak egy kezdeti szám, hogy lássa, hogy az infrastruktúra valóban működik-e. A későbbiekben ez az érték feljebb lesz emelve.

A kritikus ahelyett, hogy ezt elfogadta volna, azt állította, hogy a Red Hat biztonság terén kb. azon a szinten van, mint a Microsoft (Arjan van de Ven és Molnár Ingo - az exec-shield fejlesztői - a Red Hat alkalmazottai).

Ezekből a kijelentésekből nagy flame lett, amelyben Linus felszólította a kritizálót, hogy fejezze be a flame-et. Linus szerint bizonyos ``security expert''-ek nem képesek nagyban gondolkozni. Csak azt nézik, hogy az általuk fontosnak tartott hibák javítva vagy megelőzve legyenek, de azt nem, hogy ettől akár a felhasználók/ügyfelek nagy része használhatatlan kernelhez jut.

A thread itt.

( anr | 2005. 01. 28., p – 19:59 )

Mi az oka, hogy nem az merül fel, hogy a PAX kerül a kernelbe?

Szép és jó dolog amiket írsz (meg is veszem, ha megjelenik CD-n és kazettán ;), de a PaX Project is egy folyamat volt, az sem a semmiből vált hirtelen ilyenné. A PaXTeam több mint 4 évnyi munkája van benne és a fejlesztés eredménye egy olyan megoldás amely Posix compliant és amellett teljeskörű védelmet nyújt a 'shellcode injection' típusú támadások ellen. A megoldás jól dokumentált és a leírások remekül osztályozzák a különbőző típusú támadási formákat, amelyek ellen vagy tökéletes védelmet nyújt, vagy a lehető legjobbat, amelyet abban a szituációban lehet. A jelenleg megoldatlan problémákra is ötleteket ad a PaX future listája (mint pl. az a leendő fordító patch, amely sokkal jobb védelmet nyújtana a ret2libc típusú támadások ellen, mint a jelenleg létező Propolice). A már elkészült megoldások nem hirtelen a semmiből váltak ilyenné, hanem rengeteg hozzáértő véleményét meghallgatva és figyelembe véve készültek el (és ez az amelyet a jelenlegi Linuxos 'security expert' fejlesztők nem tesznek meg), a PaXTeam sok olyan szakértő ötletére alapozott, akik nem csak elméletben foglalkoztak/foglalkoznak ezekkel a problémákkal, hanem a gyakorlatban is (őket most elég szépen körül írtam ;). Ezek után talán nem árulok el nagy titkot, ha azt mondom, hogy underground körökben is a PaX megoldását tartják a legjobbnak.

A Linux valaha azért volt szép és jó, mert bárki fejleszthetett hozzá és ha az tényleg megfelelő megoldás volt, akkor előbb-utóbb bekerült a fejlesztői ágba. Jelenleg a Linuxba komolyabb fejlesztéseket már csak a nagy cégek adhatnak (RedHat és többiek), a kis emberektől maximum 1-2 soros patcheket fogadnak el, amelyekről még ránézésre meglehet mondani, hogy jók vagy sem. Bármennyire is az van még a köztudatban, hogy a Linuxot önzetlen és lelkes fejlesztők készítik szerte a világon, ez mára már nem igaz.

A Linux elüzletiesedett.

> A Linux elüzletiesedett.

Nekem csak az tetszik, hogy neked minden operacios rendszerhez van egy-ket jo szavad. Ezekutan kivancsi vagyok arra az emberek altal is hasznalhato OS-re ami szerinted nem ***** (hallottunk mar arrol, hogy az OpenBSD-ben ez vicc, a Linuxban az *****..., stb.).

Nem flame, tenyleg kivancsi vagyok.

( Hunger | 2005. 01. 28., p – 11:14 )

- PaX jobb, ezen sokat nem erdemes vitazni.

- Valoban nehany program nem mukodik vele, de inkabb azokat kellene patchelgetni es nem egy gyengebb security patchet commitolni a kernelbe... Persze PaX nem fog bekerulni a kernelbe sose, szoval kar almodozni.

- OpenBSD stackgap tenyleg vicc, bar 3.6-nal mar 22 bites randomizaciora fel lehet tornaszni (sysctl -w kern.stackgap_random=8388608), ami azert annyira mar nem lenne rossz, felteve, ha x86-on nem lehetne megkerulni a W^X-et... (ret2retf technika, igaz csak spealis bugok eseten hasznalhato ki). Ami viccesebb a nagyobb stackgap hasznalatanal az a core dump, mert az egesz lefoglalt vermet menti le, ami akar igy tobb szaz mega is lehet (PaX-nal max. 4k plussz lesz a coreban). Es akkor az OpenBSD 6 bites heap randomizaciorol ne is beszeljunk...

Ez van, a security miatt kompromisszumokat kell kotni, de inkabb a userlandet kelljen patchelgetni, mint hogy egy eleve gyenge megoldas keruljon a kernelbe. Szerintem.

No flame.

Nekem errol az a velemenyem hogy ha egy ilyen megoldas bekerul a kernelbe hivatalosan (akar tokeletes akar nem), es ki lehet kapcsolni, akkor senkinek nem okoz gondot, de legalabb annyival elorebb vagyunk vele, hogy van ilyen szolgaltatas, ki lehet probalni, meg lehet tanulni a hasznalatat, es ha valaki mar ott tart hogy ez keves neki, akkor ugyis valami komolyabb megoldast fog keresni helyette.

Szerintem ezzel az a baj, hogy ha van ilyen "hivatalosan" akkor az hasmis biztonsagerzetet nyujt, ami meg veszelyesebb lehet mintha egyaltalan nem is lenne ... Akinek kell, es aki ert hozza az ugyis tudja hogy mit hogyan tud tenni a biztonsagi novelese erdekeben. Ha meg ezt valaki nem tudja (marmint hogy pl honna milyen patch-et tud szedni stb) akkor annak nem is szabadna ezzel a megoldassal elnie mert egyszeruen nem tudja esetleg azt sem hogy ennek mik a hatulutoi, stb.

Amugy teny, hogy kernel bizeralasaval azt soha nem lehet 100%-osan megoldani ami hiba nem is ott van, lehet probalkozni de tokeletes sose lesz :(

No flame: kritika.

Minden egy folyamat. Az, hogy hőbörögnek, nem megoldás. Az überfasza security rendszerek nehezebben menedzslehetők és nem kompatibilsek semmivel, csak amit eleve hozzá írtak. A mostani dolgo egy kiindulási alap. Idő kell a nagy cégeknek, akik linux alapú megoldást adnak ki, hogy ők is változtassanak. Most bevezetik ezt. Ezután a menedzsment fejében mgszületik, hogy ok, ez jó reklám is, a fejlesztők pedig elkezdhetnek dolgozni a következő verzión, ilyen módon. Ha egyátalán nincs benne, akkor ez soha nem jön el. Egyébkét is: elég szomorú, ha a biztonságod ezen múlik. Egy patch nem old meg semmit. Akkor sem, ha sok mindent korlátoz és sok hasznos funkció van benne. A biztonság nem csak a szigorúan bitekkel megvalósított dolgokból áll. Van menedzsment, van felépítés stb. Vannak tervek, hogy mikor mit kel tenni, van megfigyelés, ellenőrzés, változáskövetés. s még nem mindent soroltam fel...