Exec-shield a Linux 2.6.0-test8 kernelhez

Címkék

Portoltam Molnár Ingo exec-shield patchét a napokban megjelent 2.6.0-test8 kernelhez.

A stuffot letöltheted innen: exec-shield-2.6.0-test8

Az alábbi programokkal lett tesztelve:

libsafe-2.0-16.tgz, paxtest-0.9.3.tar.gz

Az exec-shield telepítése itt. Az exec-shield-hez kapcsolódó HUP cikkek itt.

Az eredmények:===========================================

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# echo "2" > /proc/sys/kernel/exec-shield

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# cat /proc/sys/kernel/exec-shield

2

===========================================

libsafe-2.0-16 (exec-shield teljes védelem):

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./canary-exploit

This program tries to use printf("%n") to overwrite the

return address on the stack.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./exploit-non-exec-stack

This program demonstrates how a (stack) buffer overflow

can attack linux kernels with *non-executable* stacks.

This is variation on return-int-libc attack.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t1

This program tries to use strcpy() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t1w

This program tries to use strcpy() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t3

This program will exec() a new program. The new program will

overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t3w

This program will exec() a new program. The new program will

overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t4

This program will fork() child process, and the child

will overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

parent process terminating

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t4w

This program will fork() child process, and the child

will overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

parent process terminating

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t5

This program tries to use strcat() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t6

This program tries to use scanf() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

*************************************************

*************************************************

===========================================

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# echo "2" > /proc/sys/kernel/exec-shield

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# cat /proc/sys/kernel/exec-shield

2

===========================================

paxtest-0.9.3 (exec-shield bekapcsolva):

--------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/paxtest-0.9.3# ./paxtest

PaXtest - Copyright(c) 2003 by Peter Busser

Released under the GNU Public Licence version 2 or later

It may take a while for the tests to complete

Test results:

PaXtest - Copyright(c) 2003 by Peter Busser

Released under the GNU Public Licence version 2 or later

Executable anonymous mapping : Killed

Executable bss : Killed

Executable data : Killed

Executable heap : Killed

Executable stack : Killed

Executable anonymous mapping (mprotect) : Killed

Executable bss (mprotect) : Vulnerable

Executable data (mprotect) : Vulnerable

Executable heap (mprotect) : Vulnerable

Executable shared library bss (mprotect) : Vulnerable

Executable shared library data (mprotect): Vulnerable

Executable stack (mprotect) : Vulnerable

Anonymous mapping randomisation test : 16 bits (guessed)

Heap randomisation test (ET_EXEC) : 13 bits (guessed)

Heap randomisation test (ET_DYN) : 13 bits (guessed)

Main executable randomisation (ET_EXEC) : No randomisation

Main executable randomisation (ET_DYN) : 12 bits (guessed)

Shared library randomisation test : 12 bits (guessed)

Stack randomisation test (SEGMEXEC) : 17 bits (guessed)

Stack randomisation test (PAGEEXEC) : 17 bits (guessed)

Return to function (strcpy) : Killed

Return to function (memcpy) : Executable shared library bss : Killed

Executable shared library data : Killed

Writable text segments : Vulnerable

gmicsko03:/home/trey/devel/exploit/paxtest-0.9.3#

Hozzászólások

Mar bocs, de az Intel igen is ad hozza hardveres tamogatoast, csak sajna a Linux a 2.2.x-es kernelektol kezdve valamiert nem hasznalja. Az ok egyes konyvek szerint a konnyebb portolhatosag. :(((

A hardveres vedelem neve Szegmentalas. A Szegmentalast lapozassal is lehet egyutt hasznalni. Ez megfelelo vedelmet ad buffer tulcsordulasok eseten. Persze ehhez a kernel memoria managgerenek jol kell megirva lennie. Pl: Ne engedjen code szegmensre adatszegmenst definialni, jo legyen az altalalnos vedelmi kizaras kezeloje. Ennyi. Tenyleg, tudja valaki a pontos okat, hogy miert is van kiveve a segmentalas?

Jelenleg minden szegmens 0 hardver-es memcimen kezdik es asszem 4 GB-os a meretuk.

Ha hasznalnak a szegmentalast, akkor nem kellene az Ingo fele patch.

Van arra esely, hogy az exec-shield bekerul a hivatalos 2.6 kernelbe?

Andras

Es a cikkben milyen igaza is van, ha erre alapozva tagadja meg. Senkise ringassa magat tevhitben, hogy vedve van, mikor rossz programok tomkelege veszi korul, amelyek csak arra varnak, hogy mikor lepjek meg a tulajdonosukat biztonsagi hibaval.

Inkabb biztonsagosabban kene programozni a felhasznalt programokat.

Bar ettol fuggetlenul lehet nagyon jol megirva az exec-shield patch, nem garantalhato 100%osan, hogy minden extrem korulmeny kozott vedeni fog.

Sajnos ez nem olyan egyszeru. Maga az Intel (de pl. a ppc, vax) sem architektura nem biztositja az ehhez szukseges hardveres tamogatast. Ezt programbol meg lehet ugyan valositani, de ``komolyabb'' platformokon (sparc, alpha, hppa) erre van megfelelo tamogatas a vasban. Hiaba probalnak meg a fejlesztok jol programozni, ha nincs meg a megfelelo hatter.

A legtobb problema C illetve C++ ban irt programoknal abbol adodik, hogy a tarterulet veget hibasan ellenorzik a programozok - ehhez pedig letezik megfeleloen viselkedo fuggveny is, amelynek meg lehet mondani, hogy hol a tarterulet vege.

Kulonben nem allitottam, mint ahogy Linus se allitotta, hogy ne hasznald. Egyszeruen arrol van szo, hogy senki se higgye 100%os megoldasnak. Az, hogy nem reklamozzak 100%os megoldaskent egy fair dolog - az ajtodra se ugy szereled a zarat, hogy 100% meg fog vedeni.