exec-shield a stabil 2.6.0 kernelhez

Kernel

Hozzáreszeltem a Molnár Ingo-féle exec-shield patchet a stabil 2.6.0-ás Linux kernelhez. A patch a puffer túlcsordulási hibák nagy része ellen hatékony védelmet nyújt, amint azt a mellékelt ábra mutatja. Az exec-shield-nek szerves része a PaX non-executable verem és heap logikája.Mivel jelenleg még nem érhető el Grsecurity patch a legfrissebb stabil kernelhez, talán hasznos lehet azoknak, akik szeretnék az új kernelt futtatni, de kicsit több biztonságot szeretnének, mint amit a vanilla kernel biztosít.

Letölthető innen. Telepítése, használata itt.

A bugreportok hasznosak lehetnek. Aki ilyet szeretne kuldeni:

trey () hup ! hu

( hsi | 2003. 12. 22., h – 10:29 )

"Az exec-shield szerves része a PaX." - hmm, vannak bizonyos funkciok, melyek az exec-shield -ben is megtalalhatoak hasonlo vagy mas implementacioban, de a mondatbol nekem az jott le, mintha a PaX reszhalmaza lenne az exec-shield -nek => az exec-shield legalabb annyit nyujt, mint a PaX.

az emlitett levelben szerepelt tesztet erdemes lenne megismetelni az uj paxtest-tel is (v0.9.5), ugyanis a regebbi paxtest-ek kicsit "kedveztek" az exec-shield-nek. reszletek itt [marc.theaimsgroup.com].

nem, bizonyos reszei a PaX-nak megtalalhatoak az exec-shield-ben is (non-exec verem és heap logika ja jol tudom).

>az emlitett levelben szerepelt tesztet erdemes lenne megismetelni az uj paxtest-tel is (v0.9.5), ugyanis a regebbi paxtest-ek kicsit "kedveztek" az exec-shield-nek

azt hiszem mar teszteltem, es mintha ugyanaz lett volna az eredmeny. de megnezem megegyszer.

a teszt jo, azt mutatja ami tortenik. amit a regi teszt nem mutatott az az, hogy az ES-nek van egy alapveto hibaja (uaz. mint az OpenBSD i386 implementaciojanak is egyebkent), amirol az Ingo bolcsen hallgat. a hiba (ami a procibol jon, tehat nem igazan lehet javitani az ES-ben, csak a PaX oldja meg jol) az, hogy amikor az ES vegrehajthatova teszi a vermet, akkor nemcsak a verem valik vegrehajthatova, hanem minden memoria terulet, ami alatta van (es mivel a verem van a legmagasabb cimen, ezert tenylegesen is minden terulet vegrehajthatova valik - ezt mutatja az uj teszt). a PaX nem szenved ettol a problematol mivel itt normalis, laponkent allithato non-exec tulajdonsag van. az egy mas dolog, hogy a legbiztonsagosabb 'kiszerelesben' a non-exec tulajdonsag egyaltalan nem allithato bizonyos memoria teruleteken (ez amugy egy masik tulajdonsag amit Ingo nem ertett meg es nem is rakta be az ES-be).

persze egy felhasznalo szamara a vegso kerdes az, hogy hol szamitanak mindezen reszletek. a valasz egyszeru: egy letezo exploit konnyen modosithato ugy, hogy mukodjon az ES alatt mivel egy sima szimulalt fuggvenyhivassal minden terulet vegrehajthatova teheto es az exploitban levo kod vegrehajthato, PaX alatt ez nem megy (itt csakis szimulalt fuggvenyhivasok mukodnek, es remelhetoleg azok sem par honap mulva).

( trey | 2003. 12. 22., h – 12:53 )

A teszt eredmenyeim az LKML-en itt [marc.theaimsgroup.com]. Mingo valasza itt [marc.theaimsgroup.com].

Szerinte a tesztben van a hiba:

* Gabor MICSKO wrote:

> Any idea?

yes. Undo the patch below. The paxtest author decided to add this pointless mprotect(stackptr, PROT_EXEC) to make sure the test lists exec-shield as 'vulnerable' while listing PaX as non-vulnerable. I sent the fix but (not surprisingly) it was not added. Marketing via testsuite eh?

ja, lattam en is a valaszat, kb. ugyanaz amit mar a debian-devel-en is elmondott. szemmel lathatolag azota sem ertette meg, mi az mprotect() tesztek szerepe... sajna ezen en nem fogok tudni segiteni.

akit erdekelnek a reszletek: egy exploit soran altalaban az tortenik, hogy a tamado kepesse valik a programvezerles (at)iranyitasara, tipikusan az altala irt kis kodreszletre, ami aztan mindenfelet csinalhat (pl. adhat egy shell-t). amit a PaX es (valamilyen szinten) az ES csinal az az, hogy a tamado altal 'befecskendezett' kod nem lesz vegrehajthato, vagyis az ilyen iranyu probalkozas azonnali programhalalhoz vezet (ami altalaban a kisebb rossz). a kulonbseg ott van, hogy a PaX alatt semmilyen modon nem lehet az ilyen befecskendezett kodot tenylegesen is vegrehajthatova tenni, mig ES alatt ez trivialis, egy szinten Redhat-tol szarmazo 'ujitasnak' koszonhetoen minden program tartalmaz egy kis fuggvenyt, ami a vermet (es ES alatt a teljes memoriat) vegrehajthatova varazsolja. egy tamadonak ezek utan nincs mas dolga, mint eloszor erre a fuggvenyre iranyitani a vezerlest es utana a sajat kis kodjara - ahogy angolul mondjak, back to square one. mondanom sem kell, mindez PaX alatt nem mukodik, a vedelem nem kerulheto meg ilyen modon. amit a tesztben levo mprotect(PROT_EXEC) csinal az pontosan ugyanazt eri el, mint amit egy tamado is csinalna (arrol nem is beszelve, hogy vannak programok amik eleve ilyen vedtelenul futnak ES alatt, de persze errol senki nem beszel).

ami a marketinges kiszolasat illeti... a paxtest, mint neve is mutatja, a PaX tesztelesere keszult, minden mas celu felhasznalasa elott nem art megerteni, hogy mit is csinal az adott helyzetben. az ES alatt a teszt regebbi verzioi hamis eredmenyt adtak, de ez szemmel lathatolag senkit nem zavart idaig (pedig Ingo a sajat bevallasa szerint vegig tisztaban volt az ES ezen hatranyaval) - akkor most ki is elt vissza a teszttel? amugy a kedelyek megnyutatasara Peter Busser ki fogja szedni az ominozus kodot a teszt kovetkezo verziojabol es helyette csak egy figyelmeztetes lesz arrol, hogy a teszt csak PaX alatt futtatva ad hiteles eredmenyt (en szemely szerint pedig azt remelem, hogy vegre az ES tabor is ir maganak egy sajat tesztet, ami aztan olyan rozsaszin kepet fest a valosagrol, amilyet ok akarnak).

>ami a marketinges kiszolasat illeti... a paxtest, mint neve is mutatja, a PaX tesztelesere keszult, minden mas celu felhasznalasa elott nem art megerteni, hogy mit is csinal az adott helyzetben. az ES alatt a teszt regebbi verzioi hamis eredmenyt adtak, de ez szemmel lathatolag senkit nem zavart idaig (pedig Ingo a sajat bevallasa szerint vegig tisztaban volt az ES ezen hatranyaval) - akkor most ki is elt vissza a teszttel? amugy a kedelyek megnyutatasara Peter Busser ki fogja szedni az ominozus kodot a teszt kovetkezo verziojabol es helyette csak egy figyelmeztetes lesz arrol, hogy a teszt csak PaX alatt futtatva ad hiteles eredmenyt (en szemely szerint pedig azt remelem, hogy vegre az ES tabor is ir maganak egy sajat tesztet, ami aztan olyan rozsaszin kepet fest a valosagrol, amilyet ok akarnak).

igen. Peter irt nekem egy hosszu levelet amiben kifejtette az allaspontjat az exec-shield-del kapcsolatban.

elvileg az, mert irta, hogy barhova forwardolhatom:

Feladó: Peter Busser peter at devbox dot adamantix dot org

Címzett: gmicsko at szintezis dot hu

Tárgy: Regarding paxtest and exec-shield results

Dátum: 22 Dec 2003 17:36:44 +0100

Hello,

Someone pointed me to a Linux kernel mailing list article you wrote about the

paxtest results for exec-shield.

Paxtest is, as the name implies, written for testing PaX. I wrote it because

I didn't trust PaX. I mean, there is someone who writes a patch for Linux,

calls it PaX and claims that it does all kinds of things. But how do you know

these claims are truthful or not? Normally people who spend a lot of time

writing something are the last to tell you that something sucks, right?

Therefore I decided to write a simple testsuite. And it proved that PaX works

well.

But PaX is straightforward, it *always* denies the things it is supposed to

deny. I.e. there are no exceptions. This means that it is relatively easy to

write a simple testsuite for PaX.

You can use paxtest to test functionality of similar kernel patches. But the

results are only reliable as long as the behaviour of the patch matches the

straightforward behaviour of PaX. A patch like the OpenWall patch does this.

Paxtest is too simple for patches which have a different behaviour. It is like

trying to proof that a roof is water proof with a bucket full of water. Some

roofs need more water than what fits in one bucket to proof that it has no

leaks. Paxtest is only a bucket full, which is enough for PaX.

The additional mprotect() call was added to simulate multithreaded applications,

such as MySQL and Apache 2. You should get the same results when you link in a

threads library, initialise it and start a thread. However, it is easy to

tweak the threads library a bit to mask the vulnerability in the kernel patch.

That is why I decided to include the mprotect() call, which is exactly what a

threads library does.

I did not include Ingo's patch, because I have been very busy with development

of Adamantix. Paxtest development is a very low priority. It does what it

is designed to do: Test PaX on Adamantix. It only seems to be important for

exec-shield people to make exec-shield look good. Note that it looking good is

not the same as providing good protection... Funny that Ingo should accuse me

of ``marketing''.

If anything, I am only interested in providing good security and in people

being honest about it. I have no stock holders to please, no product to market

and no status quo to defend. Therefore I can afford to be honest about this

stuff. More than a month ago, someone sent me another test for paxtest which

showed yet another vulnerability in exec-shield. And I rejected it. That proves

how much I am interested in discrediting exec-shield.

But back to paxtest. I am going to remove the exec-shield specific test in the

next version. And I will replace it with a warning which will say that the

results of paxtest are not reliable when used to test other patches. Anyone

who insists in doing it anyway is from then on knowingly trying to mislead

people.

BTW, feel free to forward this e-mail message to wherever you want when you feel like it.

Groetjes,

Peter Busser