SELinux és PaX kérdések

Security-all

Adott egy probléma:

SLES11 SP1-ben szeretnék két cron példányt futtatni. Egyet a rendszerfeladatoknak, és egyet a felhasználóknak. Az előbbi férjen hozzá minden erőforráshoz, amihez eddig, kivéve a felhasználói crontabokat, az utóbbi pedig csak a felhasználói crontabokhoz, és még néhány, erősen behatárolt körbe eső objektumhoz, pl wget /dev/null, hálózat, stb. Úgy gondoltam, valamilyen MAC megoldást veszek igénybe, és úgy döntöttem, hármat vizsgálok meg részletesebben: SELinux, AppArmor, RSBAC. Eddig a SELinuxon rágtam át magam, meg az RSBAC-on kb. félig, az AppArmorra pár pillantást vetettem, és megismerkedtem a PaXszal is (ami ugye másra való, de lazán kapcsolódik).

Úgy látom, nem a SELinux az én esetem, mégpedig többek között az alábbiak miatt:

-A processzeknek és más objektumoknak nem a linuxban már meglevő tulajdonságait használják fel az osztályozásukhoz, hanem újakat adnak hozzá, és csak ezekkel dolgoznak (ortogonalitás).

-Ennek ellenére ezek az új tulajdonságok mégiscsak közvetlenül hozzá vannak csatolva a fájlokhoz, tonnányi xattr formájában.

-Az új tulajdonságok az én ízlésem szerint nem elég rendszerközeliek, hanem túl magasszintűek, absztraktak.

-Borzasztóan bonyolult a szabályrendszere, még a legegyszerűbb RedHat házirend, a "targeted" nevű is többszázezer szabályból áll.

-A házirend forráskódból binárissá fordítása nem a betöltéskor történik, hanem előtte külön le kell fordítani. A házirend forráskódja külön RPM csomagban van, és a módosításához, lefordításához komolyan pilótavizsga kell. Rosszabb, mint annak idején a Sendmail.

-Újabban moduláris házirendek vannak, vagyis a kernelben levő házirendet menet közben ki lehet egészíteni kisebb házirend-modulokkal, ami megkönnyítené a rendszergazdák dolgát, de:

-A moduláris házirendek megjelenése óta a disztribútorok nem szállítják a magházirend forrását, ezért az nem módosítható.

-A bináris házirendekben CSAK megengedő szabályok vannak (tiltó szabályok azért nem léteznek, mert mindent tilos, amit nem szabad), ami jó, mert az azonos eseteket leíró szabályok sosem ütköznek egymással, viszont cserébe:

-Amit a magházirend megenged, azt a forrás átírása, újrafordítása, újratöltése nélkül nem lehet letiltani. A rendszergazda tehát csak engedékenyebbé tudja tenni a házirendet, szigorúbbá nem! Kivéve, ha megvan neki a házirend forrása, amit viszont minden biztonsági frissítéskor újra módosítania és fordítania kellene...
... ha egyáltalán leszállítaná neki a disztribútor:(

Jól látom, tényleg így van? Ilyen nehéz lenne szigorítani SELinuxban? Akkor ez eléggé egy a rendszerekhez drótozott megoldásnak tűnik, amire a rendszergazdák számára gyárilag kiteszik a "ne piszkáld" címkét. Vagy rosszul látom? Van benne tapasztalatotok?

Más: Úgy vettem ki, mióta az NX bit támogatás megjelent, és a 2.6.30-as óta javítottak a vanilla kernel ASRL-jének véletlenszerűségén, már nem igazán van szükség a PaX-ra, főleg, ha a programcsomagok mind úgy vannak fordítva, hogy a rendszerverem ne legyen végrehajtható (és egyáltalán egyik írható memórialap se legyen végrehajtható). A SuSE ilyen, ráadásul ezt már régóta megfejelik stack-protector és fortify-source védelmekkel is MINDEN programcsomagnál, úgyhogy nem érzem szükségesnek a PaX erőltetését, főleg, hogy nem fut Xen-en, ami miatt ha akarnám, sem tudnám használni. Jól gondolom, hogy nincs rá szükségem?

( NagyZ v | 2011. 08. 05., p – 23:03 )

jelenleg 4 van a mainline kernelben: selinux, apparmor, tomoyo es smack. az RSBAC-ot meg nem neztem.

az selinuxnak vannak a legkiterjedtebb lehetosegei, en mindenkepp arra mennek a helyedben, de majd jon mindjart Hunger, es megirja, hogy fos, pedig az otlet nagyon is jo, csak volt nehany elkeffentett dolog a kernelben, amit azota fixaltak.

aztan sorban:

- igen, bevezetik a user:role:label security contextet, ez szerintem hasznos. a linuxos alap DAC nem eleg jo.
- igen. pontosabban a processekhez a process contexten keresztul, de ez reszletkerdes. es?
- pontositanal? szeritem teljesen megfeleloek.
- igen, a learning curve eleg magas, de utana... :-)
- baromsag. altalaban nem az alap hazirendet bovited, hanem bevezetsz uj labeleket, roleokat, usereket, ezekhez pedig sajat policy modult forgatsz. a teljes policy modularis, azt toltesz be, es veszel ki, amit akarsz. ennek ellenere a targeted nagyon jol atlathato.
- ... az elobbi :)
- es? miert kene? az alap, targeted policy eleg minimalis.
- pipa, tovabb:
- a base policyt (veletlen sem maghazirend) nagyon ritkan akarod felulbiralni, hiszen az tenyteg minimalis. de mutathatnal egy konkret peldat benne, ami szerinted nem kell oda.

nincs semmi ne piszkald cimke, szerintem, csak tenyleg at kell latni, de utana mar jo. en szeretem :)

PaX szakerto nem vagyok, majd megjonnek ok is, de az nem csak ASLR-bol all, illetve emulalt NX bitbol a pagekre, hanem ennel tobbbol (lasd grsec leirasok, pl stack nullazas process exitkor).

A SLES-hez nem jár policy! Rágányolhatnám a Tresys féle referenciaházorendet, belőhetném pam_namespace-estül meg pam_selinux-ostul (a userspace egyéb tekintetben gyárilag támogatja), de mivel egy base policy (elnézést az általam kreált magházirend szóért) önmagában többszázerer soros, nem hinném, hogy olyan jól tudnám illeszteni a rendszerhez, mint egy disztribútor.

Azt nem vitatom, hogy a DAC nem elégséges, de a processzek sok más olyan jellemzővel bírnak, amit figyelembe lehetne venni a kéréseik elbírásánál (pl. executable fájlneve, .so fájlok, szülő processz adatai, stb.), nem tetszik nekem az az ötlet, hogy teljesen új, a meglevőtől tök független címkéket aggatunk rájuk. Valahogy az a benyomásom, hogy ilyen user/role/type besorolás nem annyira illik a nyers UNIX-okhoz, inkább valami alkalmazás-keretrendszerben, middleware-ben, vagy korszerű vállalati szintű oprendszerben (pl. Windows) tudnám őket elképzelni. De végül is ízlés dolga. Elhiszem, hogy hatékony eszköz, de nekem túl bonyolultnal tűnik. Főleg úgy, hogy tiltani nem is tud (kivéve MLS/MCS és constraints), csak engedélyezni.

nem kell suset hasznalni:)

a nyers unix nem kerdes, hiszen alkalmazasok futnak rajta. hogy mi van alatta, az teljesen mindegy. vannak eroforrasaid, felcimkezve, vannak programjaid, felcimkezve, ezekre irod a ruleokat.

a deny hianya engem is idegesit, de vegulis atirhatoak allow -os alakba (mi pont most ezt csinaltuk egy cikkhez).

> nem kell suset hasznalni:)

:) Méltányolandó vélemény.

Eszembe jutott viszont egy számomra nagyon fontos kérdés:

Az MLS/MCS rendszerben mire jó, és pontosan mit jelent a gyakorlatban a level range? Miért nem csak egy szimpla level? Nagyon sokat segítenél, ha ezt elmagyaráznád.

nem vagyok suse expert, eddig 1x volt olyan melom, hogy SLES -rol kellett migralni kompletten mindent RHEL -re, de az a fel nap eleg volt boven vele, es ha legkozelebb meghallom, duplat kerek :-)

a legjobb pelda, ami errol eszembe jut, az az, ahogy az svirt van megcsinalva rhel6ban, itt lehet errol olvasni. ha valami nem tiszta meg, kerdezz.

Ha az RSBAC megbízhatóan menne Xen alatt, és naprakész enhanced (PaX-os) kerneleket szállítana, legszívesebben azt használnám, mert tényleg vadállati módon jó. De nincs elég erőforrásuk a fejlődés követésére. Nekem csak Xen-en jó, ezért valamelyik vanilla megoldást választom.

( eax | 2011. 08. 05., p – 23:20 )

"Úgy vettem ki, mióta az NX bit támogatás megjelent, és a 2.6.30-as óta javítottak a vanilla kernel ASRL-jének véletlenszerűségén, már nem igazán van szükség a PaX-ra"

Futtass le egy paxtest-et, es csodalkozz.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

OK, meglesz. De nem azt akarom mondani, hogy rossz a PaX, csak szegény PaX team úgy járt, hogy feltalált és megcsinált valami eszetlenül zseniális dolgot, a ˝nagykutyák˝ leugatták, de aztán mégis ˝ellopták˝ az ötleteit, neki meg se´ pénz, se´ dicsőség nem maradt. (Na, persze ezt az ő szemszögéből mondom, ha a történet más oldalait is nézzük, már nem ilyen fekete-fehér mindem.)

Ezt a "vanilla kernel ASLR-je is elég random" hülyeséget a turul16 terjesztette itt hupon. Nem kell minden tökkelütöttnek elhinni amit ír. Egyrészről az ASLR soktényezős és a vanillában jóideig voltak fix címen dolgok (pl. vsyscalls, amiből legutóbb volt nagy balhé, valamint kb. alig fordítják a mainstream distrók PIE-ra binárisaikat), ami már elég lehet egy támadáshoz, másrészről az ASLR kb. a leggyengébb funkciója a PaX-nak (kvázi egy ideiglenes kényszer feature, amíg nem készül el egy jobb megoldás a problémára... [az már csak hab a tortán, hogy pont ezt másolták le agyba-főbe ;]).

Szóval igen, PaX-ra tipikusan nem az ASLR miatt van szükség. A feladatodra pedig egy PaX-ot tartalmazó grsecurity patch pont ideális lehet és annak RBAC funkciójával meglehet oldani azt, amit szeretnél.

Ha a PaX-ra nem az ASLR miatt van szükség, akkor miért baj, hogy gyenge a vanilla ASLR?

Mert így halmozottan szar a vanilla kernel? ;)

Nem csak, hogy vanilla esetén az ASLR kijátszható a fix címek miatt, de még a PaX-ban megtalálható mmap/mprotect resztrikciók se védik a memórialapokat attól, hogy az adatlapokat futtathatóvá tegye a támadó, a kódlapokat meg írhatóvá, így saját kódfuttatást lehetővé téve az adott processz kontextusában.

És ez még mindig csak a userland támadások, a PaX pedig egyedülállóan védi a kernelt is. Lásd. KERNEXEC, UDEREF, RANDKSTACK, MEMORY_SANITIZE, STACKLEAK, REFCOUNT, USERCOPY védelmeket, amelyek abszolút hiányoznak a vanilla kernelekből.

Mi lesz az ASLR helyetti végleges megoldás? Újfajta processzorarchitektúrák? Harvard-szerűek talán?

Olyan módosított fordítóprogramok, amelyek ellenőrzést építenek fordítás során a programkódokba, hogy az ún. ret2libc (ROP) támadási lehetőségek se működjenek.

Főiskolás emlékeim alapján (régen volt) a Turbo Pascal fordítóval készült programokban sokkal több futásidejű ellenőrzés van, mint a C programokban, amelyek gyakorlatiag nem csinálnak mást, mint amit a programozó előír. Pl. a stringek nem nullára végződnek, hanem az első bájtjuk tartalmazza az aktuális hosszot, így futásidőben ellenőrizhető és megakadályozható a túlcsordulás.

Valamit valamiért! Meg tudnád szakérteni a kiposztolt paxtest eredményeimet (egybevetve azzal amit a SuSE userlandról írtam)? Még annyit hozzátennék, hogy a felhasználóknak shell hozzáférést nem adok (ha mégis, csak rbash-t egyetlen könyvtárral a path-ban), a home könyvtárak gyökereit, és a bennük levő konfigfájlok egy részét csak a root írhatja, az sftp chroot-os, az userminben crontabot átmenetileg nem adok (ld. a posztban), MINDEN könyvtárat, amit a felhasználók is írhatnak noexev,nodev opcióval mountolt fájlrendszeren tartok, stb. Ilyen körülmények között is vállalhatatlannak tartod a fentebb kirakott paxtest eredményeket?

Valamit valamiért!

Így van. a PaX készülő megoldása azért lesz jobb, mint az ilyen futásidejű buffer overflow ellenőrzések, mert nem magának a túlcsordulásnak a _tényét_ próbálja ellenőrízni és ellene védekezni - ami lassú és nehéz -, hanem annak _kihasználása_ ellen nyújt védelmet, így csak néhány plusz utasításra van szükség végrehajtásáramlás-változás (sic! :) előtt. Emiatt nem lesz annyira lassú és majd a kernel is védhetővé válik vele anélkül, hogy több száz százalékos overhead keletkezzen.

Még annyit hozzátennék, hogy a felhasználóknak shell hozzáférést nem adok (ha mégis, csak rbash-t egyetlen könyvtárral a path-ban)

Az (r)bash is tartalmaz biztonsági hibákat, ráadásul ezeket már lokálisan lehet kihasználni így, amely ellen az ASLR pláne nem véd semmit (tele van infoleakkel a userland, lásd /proc/{pid}/maps és hasonlók).

MINDEN könyvtárat, amit a felhasználók is írhatnak noexev,nodev opcióval mountolt fájlrendszeren tartok

PaX nélkül a noexec mount kijátszható. {Shell,Perl,Python,Ruby,etc.} szkriptek futtatásához pedig egyébként sincs szükség exec mountolt filerendszerre.

Ilyen körülmények között is vállalhatatlannak tartod a fentebb kirakott paxtest eredményeket

Én igen, de ettől neked még megfelelő lehet. :)

> a PaX készülő megoldása azért lesz jobb

Ha Xen alatt stabilan futni fog, feltelepítem, dögöljek meg!

> lásd /proc/{pid}/maps és hasonlók

Ez nekem is eszembe jutott, mikor azt írtad, hogy infoleak, de úgy látom, minden processz csak a vele megegyező UID-ű processzek memóriakiosztását olvashatja ki a /proc-ból. Nem mondom, hogy ez elhanyagolható infoleak, de ezeknek a processzeknek a jogosultságaival úgyis rendelkezik (csak nem birtokolnak valami extra POSIX capability-t).

> PaX nélkül a noexec mount kijátszható.

Hogyan? (Ez nem flame kérdés, ahogy a többit sem szánom annak, tisztában vagyok az IT-biztonság terén meglevő erőviszonyainkkal, ezért is örülök neki, hogy egyáltalán válaszolsz a kérdéseimre.)

> szkriptek futtatásához pedig egyébként sincs szükség exec mountolt
> filerendszerre.

Shebang-gel nem, arra bad interpreter hibát kap az user, az interpreterek meghívását pedig a rbash nem engedi (mondjuk, már a shebang-es módszert sem). Ha pedig ezeken is áthámozná magát, hogy veszi rá az interpretert vagy más processzt, hogy mmap/mprotect-tel írható és végrehajtható page-et hozzon létre? Ha ez sem megy, akkor pedig mivel nyújt több védelmet a szkriptek ellen a PaX?

en SELinuxoznek... :)

de inkább NetBSD-zel :p

termeteszetesen a kernel hibak kihasznalasa ellen nem ved (semmi 100%osan...)

végletekben gondolkodva nyilván nem, ellenben egy naprakész grsec/PaX kernel nagyságrendekkel nehezebben támadható... (annyival, hogy az utóbbi években napvilágot látott eseteknél is csak user jogokat tudtak szerezni, rootot nem... lásd a Google alkalmazott Julien Tinnes esetében is [btw, milyen meglepő, hogy a Google Security Team tag{ok} is grsec/PaX-ot használ{nak} ;])

de egy rendes confined environmentet ossze lehet vele rakni

nyilván kinek mi a rendes ;D

mostanaban selinuxozok a meloban, pl :)

egyetertunk, szerintem kiraly dolog a grsec/PaX. mondtam valaha mast? csak szerintem ket kulon feladatra talaltak ki a kettot. javits ki, ha tevedek, de a grsec/PaX elsodleges celja a kernelt nehezebben tamadhatova tenni, es az exploitokat ellehetetleniteni; az selinux celja meg inkabb az egyes alkalmazasok bezarasa megfelelo szabalyok koze.
szerintem a kettonek egyutt van ertelme, igazan.

tenyleg, az ugy mukodik? grsec ugysem LSMet hasznal:)

amugy az nem igaz, hogy csak user jogokat szereztek, lasd spender/paxteam altal agyonalazott stackjacking, amit ugyan nekialltak kifixalni, a fejlesztoket meg mindenfele hypevadasznak beallitottak, pedig csak bemutattak egy tamadast. de gondolom ismered a sztorit. :)

tenyleg, az ugy mukodik? grsec ugysem LSMet hasznal

Működni működik, a kérdés az, hogy mennyi értelme van. Az alkalmazásokat betudod "zárni" grsec RBAC segítségével is. Ráadásul van learning-mode, úgyhogy nem neked kell kitalálni hozzá a szabályokat.

amugy az nem igaz, hogy csak user jogokat szereztek, lasd spender/paxteam altal agyonalazott stackjacking

Én a valóságról beszéltem, tényleges kompromitációkról. A stackjacking egy elméleti támadást mutatott be, amely valószínűleg kivitelezhető lett volna a gyakorlatban is, de ezt még a szerzők sem bizonyították és nem tudni olyan támadásról, ahol ezt a technikát ténylegesen használták volna.

Egyébként PaXTeam nem alázott senkit, pláne a stackjacking szerzőit. Ő elismerte a munkájukat és sehol sem nyilatkozott róluk semmi rosszat, csak spender kapta fel a vizet azon, hogy az előadás előtt nem sokkal szóltak csak neki a témáról és hogy kifigurázták a prezentációban.

amit ugyan nekialltak kifixalni

Nem fixálták, mert nem voltak hibák, hanem további hardening megoldásokat dolgoztak ki, amelyek ellehetetlenítik a bemutatott támadási módszereket.

Sőt, azóta PaXTeam ismét úttörősködött és a 4.5-ös gcc-nél megjelent plugin funkciót kihasználva - gyakorlatilag elsőként - olyan plusz fordításidőben működő megoldást dolgozott ki, amely intelligensen eldönti, hogy mikor van szükség a kernel stacken potenciális infoleakek törlésére és melyik struktúra tagokat lehet konstanssá tenni (-> .rodata). Ez utóbbinak köszönhetően 800k-val csökkentette mellesleg a PaX patch méretét (spender ettől még továbbra is manuálisan karbantartja az explicit constify patcheket a grsec-ben, amíg bírja).

a fejlesztoket meg mindenfele hypevadasznak beallitottak

Mondom, ne beszélj többesszámban, mert PaXTeam nem állított be semmit és senkit semminek... Spender volt kiakadva, az más kérdés, hogy mennyire jogosan.

Az mondjuk tény, hogy nagyobb volt a hype, mint pl. PaX innovációi körül, hisz erről az egyedülálló gcc pluginjéről se lehet nagyon olvasni sehol sem, pedig abszolút úttörő és egyedi. Gyanítom pár év múlva majd halálra fogják másolni az ebben lévő ötleteket is.

És miután a fentiekből összeállt a fejemben egy olyan SELinuxra vonatkozó gondolati modell, ami úgy-ahogy kielégített engem, néhány részletkérdés tisztázásában segítettek ezek:

http://www.nsa.gov/research/selinux/list-archive/0609/16930.shtml
http://www.nsa.gov/research/selinux/list-archive/0605/thread_body8.shtml
http://selinux-mac.blogspot.com/2009/06/multi-category-security.html

Ha Xen alatt stabilan futni fog, feltelepítem, dögöljek meg!

miben nem stabil?

minden processz csak a vele megegyező UID-ű processzek memóriakiosztását olvashatja ki a /proc-ból.

és ez nem elég akkor, amikor épp a saját (r)bash processzedet exploitálod?

Hogyan?

milliószor ki lett tárgyalva hupon, keress rá.

Ha pedig ezeken is áthámozná magát, hogy veszi rá az interpretert vagy más processzt, hogy mmap/mprotect-tel írható és végrehajtható page-et hozzon létre?

Inkább az a kérdés, hogy mi akadályozná meg ebben... Sőt abban, hogy egyből egy kernel exploitot futtatva rootot szerezzen. :)

Ha ez sem megy, akkor pedig mivel nyújt több védelmet a szkriptek ellen a PaX?

Leírtam már. Azon felül a grsecurityt is említettem és annak RBAC rendszerét.

> miben nem stabil?

Fut?

> és ez nem elég akkor, amikor épp a saját (r)bash processzedet exploitálod?

> milliószor ki lett tárgyalva hupon, keress rá

Akár hiszed, akár nem, megtaláltam. És azt is, hogy még magának Árpinak is te magyaráztad el.

Ha hozzáférek a /proc fájlrendszerhez, akkor igen.

> Inkább az a kérdés, hogy mi akadályozná meg ebbe

Remélhetőleg az interpreter.

> Sőt abban, hogy egyből egy kernel exploitot futtatva rootot szerezzen. :)

Na, igen. Jogos.

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomisation test : 28 bits (guessed)
Heap randomisation test (ET_EXEC) : No randomisation
Heap randomisation test (PIE) : 28 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 28 bits (guessed)
Shared library randomisation test : 28 bits (guessed)
Stack randomisation test (SEGMEXEC) : 28 bits (guessed)
Stack randomisation test (PAGEEXEC) : 28 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) : Vulnerable

Ez x86_64-en volt blackhat módszerrel.

Szóval úgy látom, hogy a vanilla linux kernel egyrészt nem trükközik az eredetileg nem relokálhatónak szánt kódok randomizálásával, és bár lehetővé teszi a W^X-et, de nem kényszeríti rá a processzeket. Ezeket eddig is tudtam, mint ahogy arról is van fogalmam, milyen extra erőfeszítéseket tesz a PaX ezen a téren.

Meg kell bíznom tehát az rpm csomagok létrehozóiban, hogy megfelelő módon fordították a csomagokat. Ez alapján úgy látom, hogy azért nem alaptalan a bizalom, de úgy tudom, hogy nem mindent fordítottak PIE-ként, csak amit kritikusnak gondoltak (különös tekintettel a hálózati szolgáltatásokra, és suid programokra).

Tudna valaki szakértői tippet adni rá, mi okozza a strcpy-ra és memcpy-ra irányuló return-to-libc támadások eredménye közti különbséget?

Meg az sem lenne rossz, ha valaki beküldené ugyanennek a tesztnek egy x86_64-es PaX kernelen elért eredményét.

Meg kell bíznom tehát az rpm csomagok létrehozóiban, hogy megfelelő módon fordították a csomagokat.

Nem sok mindent tudnak tenni az rpm csomag létrehozói a programokban jelenlévő biztonsági hibák kihasználása ellen... :)

A PIE sem segít a fix címen lévő vsyscall ellen, az infoleak hibák felhasználása ellen és a nem korlátozott mmap/mprotect segítségével legyőzőtt W^X ellen sem.

Tudna valaki szakértői tippet adni rá, mi okozza a strcpy-ra és memcpy-ra irányuló return-to-libc támadások eredménye közti különbséget?

Hogy a memcpy nem NULL-terminált sztringkezelő függvény? :)

Meg az sem lenne rossz, ha valaki beküldené ugyanennek a tesztnek egy x86_64-es PaX kernelen elért eredményét.

Találsz a neten. Nagyjából 40 bites entrópiát látni a heap/stack randomizációnál PaX alatt.

> Nem sok mindent tudnak tenni az rpm csomag létrehozói a programokban
> jelenlévő biztonsági hibák kihasználása ellen... :)

Igaz, de a PaX sem.

> A PIE sem segít a fix címen lévő vsyscall ellen, az infoleak hibák
> felhasználása ellen

Jól gondolom, hogy a PaX sem?

> a nem korlátozott mmap/mprotect segítségével legyőzőtt W^X ellen sem.

Ez tényleg igaz, de ez az egyik pont, ahol én megbízom az userlandban. Amint már írtam, a felhasználók által írható könyvtárak noexec,nodev partíciókon vannak, úgy gondolom, csak az általam felrakott binárisok futnak a rendszeren, azokat pedig mind stack-protectorral és fortify-source=2-vel fordították, a kritikusak pedig PIE ELF-ek.

> Találsz a neten. Nagyjából 40 bites entrópiát látni a heap/stack
> randomizációnál PaX alatt.

Közben láttam, de a text szegmensek randomizációjában már közel sem ekkora a PaX előnye, és a magam laikus gondolkodásával azokat vélem a legkritikusabbnak. Vagy tévedek?

Igaz, de a PaX sem.

De, pont erre született.

Jól gondolom, hogy a PaX sem?

Rosszul gondolod. PaX esetén nincs fix címen a vsyscall sem.

Ez tényleg igaz, de ez az egyik pont, ahol én megbízom az userlandban

Honnan ered ez a bizalom? ;)

csak az általam felrakott binárisok futnak a rendszeren

Legalábbis ebben reménykedsz. ;)

a text szegmensek randomizációjában már közel sem ekkora a PaX előnye

Az meg van, hogy egyedül PaX alatt nem írható a .text? :)
Nem véletlenül van rá teszt a paxtest-ben...

> De, pont erre született.

Az ASLR és a W^X által, nem? Az viszont a vanilla kernel alatt is van már, noha nem olyan erős, mint a PaX-é, és igényel némi támogatást a fordítótól (meg a programtól, hogy ne akarjon gonosz mprotect-et hívni).

> Rosszul gondolod. PaX esetén nincs fix címen a vsyscall sem.

Ez tényleg jó, és elismerem, hogy a PaX zseniális alkotás, de úgy tudom, a vsyscallba nem raknak kritikus dolgokat.

> Honnan ered ez a bizalom? ;)

Hát, tudom, hogy nem valami sok, de ezt tudom erre mutatni:
http://en.opensuse.org/openSUSE:Security_Features

> Legalábbis ebben reménykedsz. ;)

Arra törekszem, hogy a felhasználók ne hozhassanak be binárisokat (ld. fent a noexecről szóló dolgokat). Pl. a webszerver sem írhat exec opcióval mountolt partícióra. Logfájlt sem (mint ahogy semmilyen más démonnak sem engedem ezt).

> Az megvan, hogy egyedül PaX alatt nem írható a .text?

Nem az írhatóságról, hanem a randomizációról volt itt szó. Egyébként lehet, hogy hülyeséget kérdezek, de ha egy program úgy lett lefordítva, hogy a betöltődés után ne legyen végrehajtható a text (és miért lehetne), akkor csak futásidőben tudja azzá tenni magán mprotect segítségével (ezt pedig miért tenné). Tudom, hogy a PaX ezt is megakadályozza, de fortify source, ASLR és stack protector esetén azért van valamekkora védelem az ellen, hogy valaki rávegyen egy programot ilyen őrültségre. Persze olyan hibát kihasználva is megtehető ez, ami ellen a fentiek egyike sem véd, de mi van, ha én ezt gyakorlatilag elhanyagolom?

Az ASLR és a W^X által, nem?

Ezek 10 évvel ezelőtt voltak érdekesek, azóta meglehetősen sok minden került még PaX-ba, amik közül már jópárat fel is soroltam. Utánuk néztél?

Ez tényleg jó, és elismerem, hogy a PaX zseniális alkotás, de úgy tudom, a vsyscallba nem raknak kritikus dolgokat.

Turul te vagy az? :)

Persze vsyscallba nem raknak kritikus dolgokat, de a fix címe miatt már jópár évvel ezelőtt is írtak _távolról_ kihasználható kernel exploitokat rá. Volt amelyiket publikálták is.

Lehet, hogy hülyeséget kérdezek, de ha egy program úgy lett lefordítva, hogy a betöltődés után ne legyen végrehajtható a text

Ne legyen végrehajtható a text?!

de mi van, ha én ezt gyakorlatilag elhanyagolom?

Hát hanyagold el. A te döntésed, hogy milyen támadások ellen akarsz védekezni és mi ellen nem...

Nem akarlak meggyőzni, mint írtam olyan biztonsági szintet választasz magadnak amilyet gondolsz és te döntöd el, hogy mi ellen akarsz védekezni és mi ellen nem. Úgy is mondhatnám, hogy te választod ki a Védelmi Profilt... ;)

Csak arra próbáltalak rávezetni, hogy a PaX nem csak W^X meg ASLR-ből áll, így nem helyénvaló összehasonlítás, ha csupán ezt a két funkcióját hasonlítod bármi máshoz és ebből vonsz le messzemenő következtetéseket.

A PaX (grsecurityvel karöltve) jelenleg a legjobb védelmi megoldás, amit "linugzfanboiként" használhatsz. Láthatóan nem csak én gondolom így, hanem hozzám képest sokkal nagyobb szakértők és gyakorlatilag világ legnagyobb hackerei is, akik rendre elismerően nyilatkoznak PaXTeam munkájáról (nem véletlenül kapta a díjat). És még azok is úgy érzik alul van értékelve, akik nem mellesleg a PaX védelmének megkerülésén dolgoznak.

Ennek ellenére tied a választás. A PaX/grsec nem mindenhol vállalható kompromisszumokkal jár. Ahol eleve nagyvállalati üzemeltetési policy tiltja az előírt rendszertől való eltérést ott nyilván nem is jöhet szóba, ahogy sok egyéb esetben sem. Egyértelműen több munkával jár a használata és a fenntartása, mint egy disztribúció által szállított kernelnek. Ezeket mérlegelni kell és azután dönteni, kinek mi a fontosabb.

És igen, engem is anya szült.

Egyébként én a PaX+RSBAC megoldást szerettem volna választani, de nem találtam olyan kernelt, ami a kernel.org szerin stable vagy longterm, RSBAC-kel és PaX-szal patchelt vagy patchelhető, és le tudom fordítani (illetve ez még megvolt), aztán bebootol Xen-en. Ha ezeknél a lépéseknél nem ütköztem volna problémákba, és ráadásul azt is látom, hogy naprakészen követik a vanilla kernel verzióváltásait, akkor nem próbálnám "meggyőzni magam" arról, hogy jó lesz nekem a vanilla ASLR+W^X+LSM is.

ami a kernel.org szerin stable vagy longterm

Nem értem. A 2.6.39.4 stable és 2.6.32 meg longterm, mindkettőhöz van patch.

hogy naprakészen követik a vanilla kernel verzióváltásait

Most longterm support kell vagy vanilla verziókövetés? Egyébként mindegyik valamennyire megvalósul, nyilván a legújabb verziókhoz kell egy kis idő, míg portolva lesz a PaX (pl. 2.6.39.4 már van, 3.0.1 nemsokára lesz, utána meg jön a 3.1).

nem próbálnám "meggyőzni magam" arról, hogy jó lesz nekem a vanilla ASLR+W^X+LSM is

Jó lesz neked az is na, ne győzködd magad tovább. ;)

Na, ugyanaz 32 biten:

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomisation test : 12 bits (guessed)
Heap randomisation test (ET_EXEC) : No randomisation
Heap randomisation test (PIE) : 12 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 12 bits (guessed)
Shared library randomisation test : 10 bits (guessed)
Stack randomisation test (SEGMEXEC) : 19 bits (guessed)
Stack randomisation test (PAGEEXEC) : 19 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Vulnerable

Régi 2.6.27.y kernellel PaX-os x86_32-es eredmény bináris, biztonságra - finoman szólva - nem kimondottan kihegyezett disztróval: / részben ezért is van grsec/PaX-al erősítve.

Hogy legyen összehasonlítási alapod: 


Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 17 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (PIE)            : 23 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (PIE)      : 15 bits (guessed)
Shared library randomisation test        : 17 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, PIE)         : Vulnerable
Return to function (memcpy, PIE)         : Vulnerable

Hogy is mondtad ?

...és a 2.6.30-as óta javítottak a vanilla kernel ASRL-jének véletlenszerűségén, már nem igazán van szükség a PaX-ra...

A pageexec/segmexec-től és az mprotect-től nem kell megijedni, ha valamelyik alkalmazásnak sok lenne / kern.logból kiderül / ez a fajta védelem, paxctl/chpax -al egyedileg módosítható.

+ Bináris fájlokkal szemben nagyon jó még a grsec_TPE is. Ezzel kijelölhető pl. egy megbizhatatlan felhasználói csoport, aki ennek a tagja, az nem fog saját tulajdonú (=megbízhatatlan forrásból származó) bináris fájlokat futtatni, és pont. (pl. letöltés, usb pendrive on becipelés, estébé.)
Ez bináris fájlokkal szemben hatásos, szkriptek ellen nem véd. Noexec mellé kiegészítőnek ajánlott. Főleg mert enni nem kér. Nem bináris fájlok / szkriptek, stb. / korlátozottan használható.
Pl. jar fájlok (JRE) esetében is hatásos. 


oscon@osconsfortress:~/jdictionary$ java -jar jdictionary.jar
mmap failed for CEN and END part of zip file
.........
.........

kern.log: 


grsec: denied untrusted exec of ..../jdictionary/jdictionary.jar by ......./java

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

( Zahy v | 2011. 08. 08., h – 10:13 )

OFF: erre majd szabi után visszatérek

( nice | 2011. 09. 01., cs – 16:37 )

Na, sikerült a 3.0.4-es kernelt PaXszal megpatchelni, sőt le is fordult. Az alábbi opciókat használtam:

# grep -i pax .config
CONFIG_LOCALVERSION="-xenpax"
# PaX
CONFIG_PAX=y
# PaX Control
CONFIG_PAX_SOFTMODE=y
# CONFIG_PAX_EI_PAX is not set
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
# CONFIG_PAX_EMUTRAMP is not set
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_ELFRELOCS is not set
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_USERCOPY=y

Ez még semmi, ezek után problémamentesen bebootolt Xen hypervisoron, és vígan fut:

# cat /proc/sys/kernel/pax/softmode
1

Na, de most jön a feketeleves:

# ./paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux sles11-64-dev 3.0.4-xenpax #1 SMP Thu Sep 1 15:50:33 CEST 2011 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomisation test : 28 bits (guessed)
Heap randomisation test (ET_EXEC) : No randomisation
Heap randomisation test (PIE) : 28 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 28 bits (guessed)
Shared library randomisation test : 28 bits (guessed)
Stack randomisation test (SEGMEXEC) : 10 bits (guessed)
Stack randomisation test (PAGEEXEC) : 10 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) : Vulnerable

Hát, ez még rosszabb, mint PaX nélkül! Mi lehet az oka? Gyanakodjak, hogy a dmesg nem tartalmaz pax-ra utaló bejegyzéseket?

# dmesg | grep -i pax
[ 0.000000] Linux version 3.0.4-xenpax (root@sles11-64-dev) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Thu Sep 1 15:50:33 CEST 2011

Ja, igen, bocs, ez valójában egy softmode nélküli paxtest eredménye. A softmode-ot valójában később kapcsoltam be, és véletlenül azt a részt vágtam be a vágólapról. Egyébként most megint kipróbáltam, softmode-től függetlenül ugyanaz az eredmény :(

Most viszont már láttam a dmesg-ben pax-ra való utalást:

[ 92.625773] anonmap[3020]: segfault at 7ff3295f6000 ip 00007ff3295f6000 sp 00007fffffffda18 error 15
[ 92.638731] execbss[3023]: segfault at 6020a8 ip 00000000006020a8 sp 00007fffffffde58 error 15 in execbss[602000+1000]
[ 92.651802] execdata[3026]: segfault at 602088 ip 0000000000602088 sp 00007fffffffdfa8 error 15 in execdata[602000+1000]
[ 92.657007] execheap[3029]: segfault at 602200 ip 0000000000602200 sp 00007fffffffd498 error 15 in execheap[602000+1000]
[ 92.668546] execstack[3032]: segfault at 7fffffffb620 ip 00007fffffffb620 sp 00007fffffffb618 error 15
[ 92.686192] shlibbss[3035]: segfault at 7feabe21f060 ip 00007feabe21f060 sp 00007fffffffe058 error 15 in shlibtest2.so[7feabe21e000+2000]
[ 92.691753] shlibdata[3038]: segfault at 7f1d13978040 ip 00007f1d13978040 sp 00007fffffffdf48 error 15 in shlibtest2.so[7f1d13978000+2000]
[ 382.045945] anonmap[3836]: segfault at 7f5ce02c7000 ip 00007f5ce02c7000 sp 00007fffffffdbd8 error 15
[ 382.051054] execbss[3839]: segfault at 6020a8 ip 00000000006020a8 sp 00007fffffffdc98 error 15 in execbss[602000+1000]
[ 382.055575] execdata[3842]: segfault at 602088 ip 0000000000602088 sp 00007fffffffde88 error 15 in execdata[602000+1000]
[ 382.059827] execheap[3845]: segfault at 602200 ip 0000000000602200 sp 00007fffffffd958 error 15 in execheap[602000+1000]
[ 382.064042] execstack[3848]: segfault at 7fffffffb5c0 ip 00007fffffffb5c0 sp 00007fffffffb5b8 error 15
[ 382.068850] shlibbss[3851]: segfault at 7fe67c5f9060 ip 00007fe67c5f9060 sp 00007fffffffe098 error 15 in shlibtest2.so[7fe67c5f8000+2000]
[ 382.073086] shlibdata[3854]: segfault at 7ffd951f6040 ip 00007ffd951f6040 sp 00007fffffffd7e8 error 15 in shlibtest2.so[7ffd951f6000+2000]
[ 621.743584] anonmap[4535]: segfault at 7f9d6cd3c000 ip 00007f9d6cd3c000 sp 00007fffffffe018 error 15
[ 621.748422] execbss[4538]: segfault at 6020a8 ip 00000000006020a8 sp 00007fffffffd418 error 15 in execbss[602000+1000]
[ 621.752577] execdata[4541]: segfault at 602088 ip 0000000000602088 sp 00007fffffffd6c8 error 15 in execdata[602000+1000]
[ 621.756781] execheap[4544]: segfault at 602200 ip 0000000000602200 sp 00007fffffffd9a8 error 15 in execheap[602000+1000]
[ 621.761536] execstack[4547]: segfault at 7fffffffb8c0 ip 00007fffffffb8c0 sp 00007fffffffb8b8 error 15
[ 621.766509] shlibbss[4550]: segfault at 7fa5e8e4a060 ip 00007fa5e8e4a060 sp 00007fffffffd438 error 15 in shlibtest2.so[7fa5e8e49000+2000]
[ 621.771806] shlibdata[4553]: segfault at 7ffac1138040 ip 00007ffac1138040 sp 00007fffffffdd88 error 15 in shlibtest2.so[7ffac1138000+2000]

OK. Akkor a következő nekifutás:

sles11-64-dev:/usr/local/LOCALHOST/src/paxtest-0.9.9-x86 # grep -i pax /usr/src/linux-3.0.4/.config
CONFIG_LOCALVERSION="-xenpax"
# PaX
CONFIG_PAX=y
# PaX Control
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
# CONFIG_PAX_PT_PAX_FLAGS is not set
CONFIG_PAX_NO_ACL_FLAGS=y
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
CONFIG_PAX_ELFRELOCS=y
CONFIG_PAX_ASLR=y
# CONFIG_PAX_RANDKSTACK is not set
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_USERCOPY=y
sles11-64-dev:/usr/local/LOCALHOST/src/paxtest-0.9.9-x86 # ./paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux sles11-64-dev 3.0.4-xenpax #3 SMP Thu Sep 1 21:31:53 CEST 2011 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 18 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (PIE) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 17 bits (guessed)
Shared library randomisation test : 18 bits (guessed)
Stack randomisation test (SEGMEXEC) : 24 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Vulnerable

sles11-64-dev:/usr/local/LOCALHOST/src/paxtest-0.9.9-x86 # cd /usr/local/LOCALHOST/src/paxtest-0.9.9-x86_64/
sles11-64-dev:/usr/local/LOCALHOST/src/paxtest-0.9.9-x86_64 # ./paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser

Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux sles11-64-dev 3.0.4-xenpax #3 SMP Thu Sep 1 21:31:53 CEST 2011 x86_64 x86_64 x86_64 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 33 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (PIE) : 40 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 32 bits (guessed)
Shared library randomisation test : 33 bits (guessed)
Stack randomisation test (SEGMEXEC) : 40 bits (guessed)
Stack randomisation test (PAGEEXEC) : 40 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) : Vulnerable

Tehát a PT_PAX_FLAGS most ki van kapcsolva, helyette bekapcsoltam az EI_PAX-ot. Ez most azt jelenti hogy a PaX-specifikus információktól mentes (minden binárisom ilyen hagyományos) programok a lehető legerősebb PaX védelemben részesülnek a típusuktól (ET_EXEC / ET_DYN) függetlenül?

Ez most azt jelenti hogy a PaX-specifikus információktól mentes (minden binárisom ilyen hagyományos) programok a lehető legerősebb PaX védelemben részesülnek a típusuktól (ET_EXEC / ET_DYN) függetlenül?

A típustól eleve nem független, hiszen az ET_EXEC-nél (ahogy a paxtest is mutatja) nem randomizálható a kód helye (main), csak ET_DYN esetén.

minden lap többször is be van map-elve

Nem ugyanazok a lapok vannak bemapelve többször, nézd meg jobban... ;)

Vagy a file mapping 89000-8a000 egy lapnyi átfedésére gondolsz? Az a relro terület, ami először rw- volt és utána lett belőle r-- (CoW történt rajta).

miért van végrehajtható és írható és csak olvashatóbash-em

Ez a lényege a PaX egyik elvének, amit az OpenBSD-sek később W^X-nek neveztek el: elkülöníteni a kódot (csak futtathatóként, de nem írhatóként) az adattól (csak írható/olvasható, de nem futtatható), hogy ne legyen triviális egy beinjektált adatot végrehajtatni a processzorral, mint programkódot.

A csak olvasható (nem írható, nem futtatható) memóriaterület meg a konstansokat és egyéb nem változó adatokat tartalmazza.

Szerk.: látom közben kivetted a hozzászólás végét. :)

> A típustól eleve nem független, hiszen az ET_EXEC-nél (ahogy a paxtest is mutatja) nem randomizálható a kód helye (main), csak ET_DYN esetén.

Nem erre lenne jó a RANDEXEC? (Ami ezek szerint default off.) Igazából arra gondoltam, hogy egy processz kernel módú kódját védő mechanizmusok (KERNEXEC, UDEREF, RANDKSTACK) működnek-e olyankor is, amikor az user kódot védő mechanizmusokat (NOEXEC,EMUTRAMP,MPROTECT,ASRL,RANDEXEC,RANDMMAP) az ELF header értelmezése nyomán az adott processzre nézve kikapcsolja a PaX? Illetve hogyn tudom megnézni, hogy egy futó processz pontosan milyen PaX védelemben részesül?

> Nem ugyanazok a lapok vannak bemapelve többször, nézd meg jobban

Már rájöttem, és égett is a pofám rendesen. Egyébként órákkal ezelőtt kiszerkesztettem ezt a részt a kommentemből, nem értem, hogy tudtál válaszolni rá.

> Ez a lényege a PaX egyik elvének...

Ja, bocs, mondom, hogy már rájöttem. Egy pillanatra azt hittem, hogy ez a PaX obscurity patch, de aztán leesett, hogy vanilla kernel alatt is ugyanez a történet, és az is, hogy miért.

> látom közben kivetted a hozzászólás végét.

Ja, igen, én is most látom, hogy látod.

Nem erre lenne jó a RANDEXEC? (Ami ezek szerint default off.)

De, csak már nem támogatott feature (túl nagy az overheadje).

egy processz kernel módú kódját védő mechanizmusok (KERNEXEC, UDEREF, RANDKSTACK) működnek-e olyankor is

Nincs olyan, hogy "processz kernel módú kódja", kernel van meg userland és utóbbiban futó processzek. :)

A KERNEXEC/UDEREF/RANDKSTACK/USERCOPY/REFCOUNT/SANITIZE/STACKLEAK a kernelt védik, nincs processz vonzata (ha kilehetne őket kapcsolni elf header markinggal, akkor csak ki kellene kapcsolni őket a kernel exploitban és máris kihasználhatók lennének könnyen a kernel hibák ;))

Illetve hogyn tudom megnézni, hogy egy futó processz pontosan milyen PaX védelemben részesül?

/proc/{pid}/status

Már rájöttem, és égett is a pofám rendesen.

A kérdés jogos lett volna file mapping esetén (ahol valóban van átfedés).

Egyébként órákkal ezelőtt kiszerkesztettem ezt a részt a kommentemből, nem értem, hogy tudtál válaszolni rá

Úgy, hogy rányomtam a válasz linkre, aztán más teendőm akadt és csak jóval később posztoltam. ;)

> De, csak már nem támogatott feature (túl nagy az overheadje).

Őőőő, ezt azt jelenti, hogy már nincs is?

> Nincs olyan, hogy "processz kernel módú kódja", kernel van meg userland és utóbbiban futó processzek.

Akkor mit jelent az, hogy minden processz saját kernel stack-kel rendelkezik? Legjobb tudomásom szerint a kernel mindig egy processz nevében fut (gondolom a megszakítások, pl. az ütemezőé kivétel ez alól), és amikor a processz rendszerhívást hív, akkor a processzor kernel üzemmódba vált ugyan, de még mindig a rendszerhívást hívó processz nevében fut, a virtuális->fizikai memóriamapping sem változik, csak az user stack helyett egy újonnan létrehozott kernel stack-et használja a futása folyamán (egész addig, míg vissza nem tér a rendszerhívásból). Emiatt volt a 3G/1G felosztás, emiatt elég csak processzváltásonként módosítani a TLB-t, stb. A "processz kernel módú kódja" alatt azt értettem, hogy a kernel kód, ami az adott processz nevében fut, amikor az rendszerhívásban van. Ez kernelkód ugyan, de a processzhez (legalábbis annak a végrehajtási folyamához) tartozik, és az utóbbi években már az ebben a szakaszban járó processzeket is félbeszakíthatja az ütemező (AFAIK).

Egyébként azt nem tudod véletlenül, hogy az i386-os időkben 3G/1G formában létező processz_virtuális/kernel memóriamegosztás x86_64 esetében milyen arányú (ha lehet egyáltalán erről beszélni)?

> /proc/{pid}/status

Nagyon király! Egyébként tegnap éjjel óta már egy viszonylag nagy terhelésű production szervert futtatok PaX-os 3.0.4-es kernelen Xen fölött, és elég jónak tűnik. Még az KERNEXEC+UDEREF kombináció sem akasztotta ki a Xent, pedig óvtak tőle. Még live migráltam is, azt is túlélte. Nem számítottam erre.

> Úgy, hogy rányomtam a válasz linkre, aztán más teendőm akadt és csak jóval később posztoltam.

Gondoltam.

Őőőő, ezt azt jelenti, hogy már nincs is?

Már évek óta. Egyes distro szállítók már igyekeznek a fontosabb binárisokat ET_DYN-re fordítani, annyival jobb a helyzet. :)

minden processz saját kernel stack-kel rendelkezik

A kernel stack az nem "kernel módú kód", hanem adat. ;)

[...] Emiatt volt a 3G/1G felosztás, emiatt elég csak processzváltásonként módosítani a TLB-t, stb.

Ez így van, ezért léteznek a userland pointer dereference hibákat kihasználó kernel exploitok, amelyek ellen véd a PaX/UDEREF. ;)

Mondjuk PaX SEGMEXEC alatt ez igazából 1.5G/1.5G/1G (a 3G userland is ketté van osztva) a VMA mirroring miatt, illetve Ingo úrnak volt olyan - nem túl jól megírt - patche RHEL3-hoz, hogy 4/4 splitet csinált és így volt teljes 4G címtér a userland processzeknek és a kernelnek. Ugyanígy nincs pl. MacOSX-nél a mai napig közös címtér, tehát ott gyakoribb a TLB flush... ;)

Egyébként azt nem tudod véletlenül, hogy az i386-os időkben 3G/1G formában létező processz_virtuális/kernel memóriamegosztás x86_64 esetében milyen arányú (ha lehet egyáltalán erről beszélni)?

Linuxnál fele-fele, 47 bit mindkettő.

Még az KERNEXEC+UDEREF kombináció sem akasztotta ki a Xent

Ha van hardveres virtualizáció támogatás (és a Xen használja is), akkor működnie kell, de mondjuk nincs túltesztelve.

> Már évek óta.

Kár. Mondjuk látom, is, hogy hiányzik az X a /proc/XXX/status fájlból.

> A kernel stack az nem "kernel módú kód", hanem adat.

Gondolom, azért sejted, hogy ezt még én is tudtam :(

> Mondjuk PaX SEGMEXEC alatt ez igazából 1.5G/1.5G/1G

Ja, rémlik valami, de ha jól veszem ki ez x86_64-en már nem aktuális.

> Ingo úrnak volt olyan - nem túl jól megírt - patche RHEL3-hoz, hogy 4/4 splitet csinált és így volt teljes 4G címtér a userland processzeknek és a kernelnek.

Nem gyenge...

> Linuxnál fele-fele, 47 bit mindkettő.

Köszi.

Még az KERNEXEC+UDEREF kombináció sem akasztotta ki a Xent, pedig óvtak tőle. Még live migráltam is, azt is túlélte. Nem számítottam erre.

A KERNEXEC & UDEREF leginkább szvsz bináris kerneldriverekkel akasztható ki.

x86_32 alatt pl. egy tipikus jelenség, ha modprobe betöltésekor "Cannot allocate memory"-val jelentkezik és a vmalloc növelését ajánlja, ilyenkor a KERNEXEC 4MB-t 8-ra kell emelni a vmalloc állítás helyett. Ez a jobbik eset.

A rosszabbik nyilván egy fagyogatós téma. Ilyenkor nem biztos, hogy a PaXban van a hiba, nem egyszer előfordult, hogy KERNEXEC fagyogatást követően hirtelen az említett bináris kernelmodulra biztonsági leírás, és új verzió érkezett, amivel változatlan PaX mellett nem jött elő a fagyogatásos történet.

Mindenesetre bináris kernelmoduloknál a KERNEXEC használatát meg kell fontolni, mert nem várt mellékhatásokkal járhat. Erre a PaX ot nyílván nem nagyon lehet felkészíteni teljes biztonsággal.

A bináris fájlokról a chpax-al (EI_PAX) ill. paxctl-el (PAX_FLAGS) is levehető az MPROTECT/SEGMEXEC/PAGEEXEC védelem. paxctl csak konvertálás után használható (paxctl -C), vagy eleve pax-al patchelt binutilst kell használni a binárisok fordításához.
A paxctl használata egy binárison egyirányú út, visszafelé nem vezet. Ha egy bináris már paxctl-t használ, nincs út visszafelé a chpaxhoz (csak ha úm. "újratelepíted/újramásolod eredeti forrásból" a bináris fájlt, hiába állítgatod chpax-al a PAX_FLAG ek miatt már
csak a paxctl hatásos.

A kern.log bejegyzései egyértelműen utalnak arra, ha a PAGEEXEC sok egy cuccnak, de ez egy serveren nem jellemző. Ami gyakoribb, hogy az MPROTECT fexi meg egy egy alkalmazás gyomrát, de serveren szerintem ez sem valószínű. Ez inkább desktop típusú néhány alkalmazásnál fordulhat elő.

Úgy tudom újabban már van ennek detektálására grsecurity opció ami logolja az ilyen eseményeket, kis rutinnal amúgy ez is könnyen kiszúrható enélkül is, ha az ember megszokja, de még egy kis rutin után már fejből megy hogy pl. X & Nvidia GL nem bírja az mprotectet, akkor JAVA JRE, xulrunner-stub, soffice.bin, stb..
Ezeket szerintem serveren nem használod. ;-)

Ha egy alkalmazás gyanús, akkor előszőr mindig az mprotect-et kell levenni, utána a pageexec/segmexec -et.
De utóbbira nem hiszem, hogy sok példa van, talán a wine (?).

RANDEXEC kb. 2004 óta nincs a paxban, úgy tudom már nemcsak default=off, de a kódja is val'szeg végleg kikerült a kernelből 3 v. 4 éve (?).
Az alapértelmezés leginkább chpax/paxctl -zex -el állítható vissza a binárisokon.

---------
grsecurtity ACL esetén figyelni kell a verzióegyezésre, tehát 2.2.x grsec-et lehetőleg ne 2.1.4-es gradm-al próbálj állítgatni, és vice versa. Meg persze kellő óvatossággal érdemes használni, mert könnyen kitilthatod magad a rendszerből, ha csak egy speciális folyamatra használnád, érdemes megfontolni a special Role használatát és gradm -E "rolename" úm. "csak azt" bekapcsolni. Ha jól emlékszem, valahogy így működik :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

a kovetes oldalon(sajat adatok -> 2. ful) latom azokat a postokat, amiket en irtam, vagy hozzaszoltam, mellette latszik, ha uj hozzaszolas erkezett(vagy meglevo hozzaszolast szerkeztett valaki), vagy ha maga a nyitopostot szerkesztettek.
lenyeg az, hogy ha van egy post, amirol ertesulni akarsz ha frissul, akkor hozzaszolsz egyet, es onnantol kezdve konyen eszreveszed hogy mi frissult.

Tyrael

( nice | 2011. 09. 01., cs – 16:50 )

Ja, még néhány PaX kérdés:

A fent említett extra védelmek (KERNEXEC, UDEREF, RANDKSTACK, MEMORY_SANITIZE, STACKLEAK, REFCOUNT, USERCOPY) ugyanolyan hatásosak x86_64-en is, mint i586-on? (Főleg az UDERDRF-re gondolok, de ugyanúgy a többire is?) Van értelme annak, hogy 32 bites emulációval (CONFIG_IA32_EMULATION) rendelkező x86_64-es kernelt használjak 32 és 64 bites userland-ű szervereken egyaránt? Legjobb tudomásom szerint a modprobe-on kívül minden 32 bites progi ugyanolyan jól fut 64 bites kernelen, szóval minek fordítgassak kétféle kernelt? Különös tekintettel arra, hogy a sima 32 bites kernelnek is kötelezően PAE-képesnek kell lennie a 64 bites hypervisor miatt.

Egyébként, ha most valami átütő eredményt mutatott volna fel a PaX, már nem is lenne semmi kétségem.

ugyanolyan hatásosak x86_64-en is, mint i586-on? (Főleg az UDERDRF-re gondolok

Nem. Az UDEREF különböző módon van megvalósítva a két architektúrán, mivel x86_64 esetén nincs szegmentálás.

Részletek itt:

http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html

Egyébként, ha most valami átütő eredményt mutatott volna fel a PaX, már nem is lenne semmi kétségem.

Pedig csak PEBKAC fennforgás van. :)

( W3ber | 2011. 09. 02., p – 16:44 )

Üdv.
Ahogy látom ezt grsec/pax más disztróhoz is fellehet tenni elég könnyen.Megéri SElinux-szal használni?
Nice:Mire használod ezt agyon biztosított rendszered (ha publikus).
Pl freebsd+pax nem megfelőbb erre célra?

Ennél azért bonyolultabb a helyzet... NetBSD-t nem "támogatja", hanem van egy kezdetleges PaX port rá (nem mellesleg a saját közbenjárásomnak köszönhetően ;), de végül sose lett teljesen befejezve és a PaX funkciók csak elenyésző részét tudja (nem jó NX, gyenge ASLR, és erősen kérdőjeles mmap/mprotect resztrikciók, nulla kernel védelem).

FreeBSD/SEBSD teljesen más tészta. FreeBSD-ben abszolút nincs ASLR, még normális NX megvalósítás sincs (asszem a stack még mindig futtatható, mint a középkorban - fixme - :) és semmi más proaktív biztonsági megoldás sincs, amelyekkel tele van a PaX.

OpenBSD pedig a PaX ötlete alapján csinált egy saját NX és ASLR implementációt, de nincs benne se mmap/mprotect korlátozás, se olyan kernel védelmek, mint PaX-ban.

Szóval szar a helyzet BSD téren.

Hardened Gentoo teljesen jó (talán a legjobb hardened linux distro, ha valaki rátudja szánni az időt ;), grsec/PaX patcheket követik a fejlesztők, felhasználják az egyéb security ötleteket és alapból ET_DYN binárisokat produkál a fordítójuk.

ExecShield ugyanott tart, ahol 7 éve.

> ExecShield ugyanott tart, ahol 7 éve.

Akkor van még valami előnye a vanilla kernelhez képest? (Azt leszámítva, hogy a nem noexec képességekkel tervezett x86 processzorokon is nyújt noexec védelmet.)

Jó, hogy mindkét jelentős memóriakorrupció elleni Linux patch alapvetően magyar fejlesztés, de kár, hogy nem felhőtlen fejlesztők viszonya.

A toolchain-ben benne van még stack smashing protection (SSP) is, amely kernelen kívüli védelmet próbál nyújtani egyes stack overflow támadások ellen. Az eredetit Hirohi Ito fejlesztette az IBM-ben. Más Linux disztrókban (Debian, Ubuntu, Redhat) is elérhető az SSP (kicsit eltérő módon van implementálva), de nem erőltetik annyira. Van némi overhead-je. Meg a PIE-t is elég konzekvensen erőlteti a Hardened Gentoo.
Egyébként meg:
http://www.gentoo.org/proj/en/hardened/
http://www.gentoo.org/proj/en/hardened/primer.xml

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

És "-fstack-protector"-ral, vagy "-fstack-protector-all"-lal fordítanak mindent? Az utóbbi mindenhova odarakja a canary-t, az előbbe csak oda, ahova egy logika úgy gondolja, hogy fontos. Szóval nem egy szimpla boolean dolog, hogy azzal van fordítva vagy nem.
Ez a gcc spec file-tól függ. Ki lehet listázni a gcc-be beleforgatott specs-t. Bár a beépített specs-t felül lehet bírálni. Szóval nem biztos, hogy azt mutatja, amivel végül is egy disztró binárisait forgatták. Ez ilyen kondícionális állításokból áll össze. Egymásba fűzött feltételek is vannak és hivatkozásokat lehet belerakni. 


gcc -dumpspecs | grep -A 5 -B 5 stack

Nálam például a releváns sorok: 


*esp_options_ssp:
%{!D__KERNEL__:%{!nostdlib:%{!nodefaultlibs: %{!fno-stack-protector:                    %{!fstack-protector:%{!fstack-protector-all:-fstack-protector-all}}}}}}

readelf-fel lehet csekkolni, hogy mik vannak a futtatható file-ban. 


readelf -s /usr/lib/libreoffice/program/soffice.bin | grep stack
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (6)
readelf -s /usr/lib/firefox/firefox-bin | grep stack
    18: 00000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (6)

Érdemes csekkolni mondjuk a libreoffice, vagy a firefox binárist. A readelf parancs -s kapcsolójával futtatva. Az SSP megvalósítás eltérő, de szerintem ott is stack vagy guard (régi implementáció) sztringre kell keresni a kimenetben.

Illetve más dolgokat is lehet turkálni a readelf-fel.
Pl megnézni "readelf -l"-lel, hogy RELRO-val van-e linkelve a bináris. Az a jó, ha igen. 


readelf -l /usr/lib/firefox/firefox-bin | grep RELRO
  GNU_RELRO      0x00bd78 0x0000cd78 0x0000cd78 0x00288 0x00288 R   0x1

Nem tudom, hogyan állnak most ezekkel a disztrók úgy általában.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ez alapján úgy tűnik, hogy nem all.

Őőőő, ez mond valamit?
*link_ssp:
%{fstack-protector:}

sles11-64-dev:~ # readelf -s /usr/lib64/firefox/firefox | grep stack
50: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __stack_chk_fail@GLIBC_2.4 (10)

sles11-64-dev:~ # readelf -l /usr/lib64/firefox/firefox | grep RELRO
GNU_RELRO 0x0000000000014c10 0x0000000000614c10 0x0000000000614c10

Úgy néz ki, hogy az SSP bele van forgatva és RELRO-val van linkelve. Viszont a legfelső fstack-protector állítás az a linkelésre vonatkozik.

Egyébként igaza van sajnos Hunger-nek, hogy az SSP-t meg lehet kerülni. Szóval felmerülhet, hogy felesleges izmozás esetleg az egész.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

SSP meglehetősen gyenge volt már akkor amikor megszületett... Ha Hiroaki már akkor egy normális ret2libc védelmen dolgozott volna - nem olyanon, ami csak szekvenciális stack buffer overflow ellen véd és az ellen is csak akkor, ha nincs infoleak (ami mindig van ;), amivel kinyerhető a canary tartalma -, akkor most egy kicsivel jobb lenne a helyzet.

Hát igen, az SSP-vel lehet izmozni, de egy valamire való exploit rá se bagózik. Vajon mikor lesz ret2libc védelem? Annyi ideje emlegeti pipacs is...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Tényleg: Theo is azt mondja már, hogy a W^X-hez a PaX-ból merített? Van valami újdonság a good-old flame óta?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ez csak egy sima webszerver. SELonux helyett AppArmor van rajta, de kísérletezek a Linux capability-k MAC- és SETUID kiváltó képességeivel is(man 7 capabilities). Az sem rossz a 2.6;26-os kernel óta.

A SELinux-on kívül az RSBAC-cal kísérletezgetek, de szerintem végül marad az AppArmor. Hacsak nem lesz grsecurity.