paxtest log

Security-all

paxtest log

  • 1181 megtekintés

( Sallus | 2004. 09. 22., sze – 19:35 )

Koszi PaXTeam!
Ezek szerint meg a RANDEXEC-t erdemes bekapcsolni?
Esetleg tudsz valami howto lelohelyet a gradm2, paxctl-hez, policy file-ok krealasahoz?

Koszonettel,
S.

( johans | 2004. 09. 22., sze – 20:00 )

hmm.. nem a feeling miatt hasznalok debiant, hanem mert azt ismerem a legjobban, mar tobb eve azt hasznalom..
de gyozz meg, szerinted miert jobb a Hardened Gentoo, nyitott vagyok az ertelmes hozzaszolasokra.

Igazából a debian hardeningje és a hardened gentoo / adamantix között az a külömbség, hogy a debian esetében ez egy hack, amit neked kell csinálni/utánahúzni stb. , míg a másik esetekben ez az adott disztribúcióhoz tartozó feature, amin akár 10+ ember is dolgozik, és a disztribúció szerves részét képezi. Csak ennyit tudok mondani, kérem kapcsolja ki.

( Sallus | 2004. 09. 22., sze – 22:47 )

[quote:846f32122c="johans"]

hmm.. nem a feeling miatt hasznalok debiant, hanem mert azt ismerem a legjobban, mar tobb eve azt hasznalom..
de gyozz meg, szerinted miert jobb a Hardened Gentoo, nyitott vagyok az ertelmes hozzaszolasokra.

Igazából a debian hardeningje és a hardened gentoo / adamantix között az a külömbség, hogy a debian esetében ez egy hack, amit neked kell csinálni/utánahúzni stb. , míg a másik esetekben ez az adott disztribúcióhoz tartozó feature, amin akár 10+ ember is dolgozik, és a disztribúció szerves részét képezi. Csak ennyit tudok mondani, kérem kapcsolja ki.

A Hardened Gentoo letezik elore forgatott csomagokkal, vagy azt is nekem kell forgatnom mint a hagyomanyos Gentoot?
Oszinten bevallva ez a forgatos dolog az ami a Gentootol elriaszt. Nincs semmi bajom az elvvel, sot nagyszeru az otlet, hogy olyan rendszert csinalsz magadnak ami a Te geperde van optimalizalva, csak kicsit korulmenyesnek es nehezkesnek erzem... de fogalmazhatok ugy is, hogy egyszeruen nem ismerem es pont.

S.

[Talan ennek inkabb a Flame-ben lenne a helye...]

( PaXTeam | 2004. 09. 22., sze – 23:08 )

[quote:dff4ec4838="Sallus"]Ezek szerint meg a RANDEXEC-t erdemes bekapcsolni?

attol fugg, mire kell. ha csak a paxtest eredmenyet akarod javitani, akkor hajra, kulonben meg nem sok ertelme van, en nem javaslom az elesben valo hasznalatat (olvasd el a config helpjet vagy a pax doksit rola, hogy miert).

Esetleg tudsz valami howto lelohelyet a gradm2, paxctl-hez, policy file-ok krealasahoz?

van ugye olyan, hogy 'man paxctl' ;-), a gradm2-ben van egy ondokumentalo policy file. ha ezen tul van kerdesed, akkor irany a grsec forum inkabb.

( PaXTeam | 2004. 09. 22., sze – 23:13 )

[quote:e2070b6976="Sallus"]A Hardened Gentoo letezik elore forgatott csomagokkal, vagy azt is nekem kell forgatnom mint a hagyomanyos Gentoot?

jelenleg csak a stage-k leteznek (pl. http://gentoo.prz.rzeszow.pl/releases/x86/2004.2/stages/x86/hardened/ ), a kovetkezo kiadasban mar lesz minden, teljes livecd is.

( Sallus | 2004. 09. 21., k – 17:20 )

Sziasztok,

sikerult mukodo grsec-es, pax-os kernelt forditanom (Debian Linux 2.6.7), a paxtest ilyen eredmennyel zarul:

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

Hogyan tudnam a fenti hibakat kikoszorulni, egyaltalan hiba-e a "guessed" eredmeny (a "Vulnerable" es a "No randomization" gondolom az)? Milyen opciokat allitsak be, es szivesen fogadok RTFM-et is.

Koszonettel,
S.

( Sallus | 2004. 09. 22., sze – 09:37 )

Tegnap forditottam egy ujabb kernelt, de az eredmeny nem valtozott... sajnos
Megkoszonnem, ha valaki tudna kuldeni linket grsec es pax kernel konfigrol, illetve paxctl es gradm2 hasznalatrol, policy file krealasrol, stb stb..

koszi
S.

( Sallus | 2004. 09. 22., sze – 10:26 )

Nem, rogton 2.6-al probaltam, az egesz gep ugy lett epitve es most mar maradnek is annal, amennyiben hajlando lenne mukodni...
A terv az, hogy ez a gep kisebb hegesztesekkel elmukodjon meg legalabb 2-3 evig, es olyan helyzetet nem szeretnek, hogy valamilyen - szamunkra fontos - X szolgaltatasnak az ujabb verzioja mar nem tamogatott a 2.4-es kernelben..

( nc | 2004. 09. 22., sze – 10:43 )

Akkor próbáld ki előre "összehegesztett" pax-os kernellel.

( Sallus | 2004. 09. 22., sze – 12:06 )

az is megoldas lenne, de jobb szeretnem sajat magam megcsinalni..

( johans | 2004. 09. 22., sze – 12:15 )

A "guessed" sorok nem hibák, csak azt mutatják, hogy kb. hány bites random számot generál a PaX az adott funkcióhoz. A return to libc típusú dolgokat pedig nem a PaX-nak, hanem a ProPolice-nak kellene megfognia. Valószínűleg nincs ilyen patch a gcc-dben.

( johans | 2004. 09. 22., sze – 12:25 )

Ja, és kijavítani pedig Debian alatt nem lehet egyszerűen, mert a ProPolice-os (esetleg hardened-toolchain-es, pie és pic támogatású) gcc-vel minden binárist újra kellene fordítani a rendszeredben. Ha flémelni akarnék, azt mondanám, hogy úgy lehet a legegyszerűbben megoldani, hogy felraksz egy hardened gentoot, mert ott ezek alapból adottak, de mivel nem akarok flémelni ilyet nem mondok. :lol:

( Hunger | 2004. 09. 22., sze – 14:18 )

[quote:8b0fda8f67="johans"]A return to libc típusú dolgokat pedig nem a PaX-nak, hanem a ProPolice-nak kellene megfognia. Valószínűleg nincs ilyen patch a gcc-dben.

Khm, nem egészen...
A PaX-nak is meg kellene fognia szerintem, de talán kérdezzük meg a PaXTeam véleményét erről. :D

[quote:8b0fda8f67="johans"]Ha flémelni akarnék, azt mondanám, hogy úgy lehet a legegyszerűbben megoldani, hogy felraksz egy hardened gentoot, mert ott ezek alapból adottak, de mivel nem akarok flémelni ilyet nem mondok.

Vagy Adamantix és akkor megmarad neki a debian feeling... ehhe :P
De én is a Hardened Gentoot ajánlanám, ha már linux. :lol:

( Sallus | 2004. 09. 22., sze – 14:19 )

ez azt jelenti, hogy ekkor ezt nem lehet debian alatt megcsinalni?
Oscon irta itt
http://www.hup.hu/modules.php?name=Forums&file=viewtopic&t=2090&highlight=pax
hogy patchset-et keszitett a debianizalt kernelre woody-hoz ami ilyen kimenetet eredmenyezett:
[code:1:2f4b9d28d0]
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 osconsfortress 2.4.18-gekaichromage #1 2004. jún. 30., szerda, 00.59.46 CEST i686 unknown

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Killed
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Killed
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed
[/code:1:2f4b9d28d0]

De akkor ennek is a debianos gcc-vel kellett mennie, nem?

Koszi,
S.

( Sallus | 2004. 09. 22., sze – 14:23 )

[quote:a40a8aa633="hunger"]
Vagy Adamantix és akkor megmarad neki a debian feeling... ehhe :P
De én is a Hardened Gentoot ajánlanám, ha már linux. :lol:

hmm.. nem a feeling miatt hasznalok debiant, hanem mert azt ismerem a legjobban, mar tobb eve azt hasznalom..
de gyozz meg, szerinted miert jobb a Hardened Gentoo, nyitott vagyok az ertelmes hozzaszolasokra.

( Hunger | 2004. 09. 22., sze – 16:07 )

[quote:6406e8ad9e="Sallus"]de gyozz meg, szerinted miert jobb a Hardened Gentoo, nyitott vagyok az ertelmes hozzaszolasokra.

pl. hardened gentoo kernel alapból tartalmazza a PaX-ot és jónéhány security megoldást, nem kell patchelgetned... de én nem győzködlek se linuxal, se mással, mert csak flame lenne belőle. :wink:

( Sallus | 2004. 09. 22., sze – 16:10 )

jo, ok, ez telleg a Flame-be illik.
Maradjunk inkabb az eredeti temanal. Van valakinek otlete, hogy mivel lehet a sebezheto reszeket befoltozni?

S.

( PaXTeam | 2004. 09. 22., sze – 17:12 )

1. a 'guessed' ahogy mar mondtak masok is, nem problema onmagaban, csak arra utal, hogy a veletlen bitek szama meres eredmenye, es pontatlan lehet (PaX alatt altalaban max 1 bittel ter el a tenyleges ertektol, ez a meresi modszer hibaja/tulajdonsaga).

2. a RANDEXEC-kel jelolt sorok ill. az ET_EXEC randomization sor csak arra utal, hogy te a kerneledbol kihagytad a RANDEXEC-t, nem dol ossze tole a vilag.

3. a maradek 'return to strcpy/memcpy' tesztek pedig szandekosan nem sikerulnek PaX alatt, azt mutatjak, hogy az adott tesztben hasznalt exploit technika mukodik PaX alatt is. az ssp hasznalata valoban segit megfogni a konkret tamadast, de mas valtozatait nem, ezert a paxtest direkt kikapcsolja az ssp hasznalatat (egyreszt mert a paxtest a PaX-ot teszteli, masreszt mert nem akarunk 'false sense of security'-t terjeszteni). persze ha akarod, akkor atirod a makefile-t es villoghatsz ;-), de ettol meg nem leszel 100%-ban vedett a return-to-libc tipusu tamadasokkal szemben.