Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  1 647
Denne posten burde kansje havnet i unix forumet, men siden spørsmålet mitt handler om programmering stiller jeg det her.
En local exploit til 2.4.* og 2.2.* har eksistert noen måneder.
Hvis man ikke har kernel module support i kernelen er man safe.

Jeg testet exploiten på en av mine boxer. en slackware 8.1 box som kjørte 2.4.20 med grsecurity patch.
Jeg hadde kernel module support enabled, og exploiten funket fint. jeg recompilet kernelen, denne gangen uten støtte for kernel modules og testet på nytt exploiten. den fungerte fortsatt.
Dette skjønte jeg ikke helt, så jeg compilet exploiten på ny.
Den nye binary'en fungerte ikke, mens den gamle fortsatt fungerte.
Dette betyr at under compilen av binaryen finnes det frem til rette preset's for å exploite ptrace, noe den selvsagt ikke kan gjøre når kernel module support ikke er compiled i kernel.
Men det vil dog si, at om man har de rette preset's til en target box, kan denne exploites, selv om boxen ikke har kernel module support enabled. Dette er litt interesant, fordi nesten alle linux boxer i verden kjører 2.4.* eller 2.2.*.

Mitt spørsmål er da som følger, er det mulig å lage en code snutt som brutforcer seg frem til rett presets?

Noen her som har kunnskaper om det?

link til sources:

http://packetstormsecurity.nl/0304-exploits/myptrace.c
http://packetstormsecurity.nl/0304-e.../ptrace-kmod.c
http://www.security.nnov.ru/files/linuxptraceex.c

3 forskjellige versioner. alle fungerende på 2.4.20 med kernel module support.
Trådstarter
ok, glem det hele.

exploiten gjør seg selv om til en suid når den kjøres første gang successfully. noe som gjør at den selvsagt kan skaffe seg root at any given time later, uansett hva man gjør med kernelen, siden det ikke er kernelen som blir exploitet de etterpåfølgende gangene

Takker for all input anyway(hah, ingen som engang sa et lite "det går ikke")