CAN-2003-0961: privilégium szint emelés (helyi root)

Kernel

Érintett kernelverziók: 2.4.22 és a korábbi kernelek

A tegnapi Debian SA-ból következik, hogy minden Linux disztribúció használójának érdemes a 2.4.23-as kernelre (vagy a legújabb 2.6-os test kernelekre) frissíteni. Mivel a Debianban megtalált kernelhiba nem Debian specifikus volt, a többi disztribútor ``terméke'' is érintett lehet. A Mandrake már ki is adta a hibajegyét. A Red Hat szintén.

A hiba leírása:A 2.4.22-es és korábbi Linux kernelben megtalálható do_brk() függvényben hibás a határellenőrzés. Ezt a hibát kihasználva a rosszindulatú helyi felhasználó root jogokat szerezhet az áldozat gépen. Az exploit közkézen forog, úgyhogy a hibát komolyan kell venni!

A CVE bejelentése itt.

( Sea-you | 2003. 12. 02., k – 15:45 )

uname -a

Linux waxweazle 2.4.19-grsec #1 Sun Sep 1 01:16:47 CEST 2002 i586 unknown

./a.out

Segmentation fault


FYI, azert forditok mindenhova egyet :)

Ok, én is erre gondoltam, de ez megtévesztett:

"Azonnali frissítés ajánlott - ezzel a módszerrel törték meg a Debian szervereket is. Az apt-get update/upgrade páros már működik!"

Ezt lehet úgy is értelmezni, hogy valami javító csomaggal orvosolható a probléma.

Thx

ha telepitve volt pl a kernel-source-2.4.18 -as csomag, akkor egy upgrade-el siman frissul... csak forgatni kell :)

Egyebkent szerintem vmi bug van a 18-asban a "VIA DMA bug workaround" korul, mert joidombe tellt mire rajottem, h a DMA-t ki kell kapcsolnom, ha pl. egy iso-imaget akarok md5 helyesen lehuzni a netrol... (igy meg eleg tetves lett a gep...) A 2.4.23-at tesztelve minden ugy mukodik ahogy kell..

In My Humble Opinion az, hogy a grsec-es kernel megfogja-e az exploitot erosen fugg a kernelforgataskor beallitott grsec opcioktol. Nalam a (szerintem) idevonatkozo resz igy nez ki:

#

# Address Space Protection

#

CONFIG_GRKERNSEC_PAX_NOEXEC=y

# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set

CONFIG_GRKERNSEC_PAX_SEGMEXEC=y

# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set

CONFIG_GRKERNSEC_PAX_MPROTECT=y

# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set

CONFIG_GRKERNSEC_PAX_ASLR=y

CONFIG_GRKERNSEC_PAX_RANDKSTACK=y

CONFIG_GRKERNSEC_PAX_RANDUSTACK=y

CONFIG_GRKERNSEC_PAX_RANDMMAP=y

CONFIG_GRKERNSEC_PAX_RANDEXEC=y

CONFIG_GRKERNSEC_KMEM=y

CONFIG_GRKERNSEC_IO=y

CONFIG_RTC=y

CONFIG_GRKERNSEC_PROC_MEMMAP=y

CONFIG_GRKERNSEC_HIDESYM=y

( Ysolt | 2003. 12. 02., k – 18:24 )

Hali!

Felhasznalastol fuggoen nekem az alabbiak mindig bejottek:

1, grsec patch a kernelben

2, /home /tmp noexecre mountolva ezen kivul :

rm -fr /var/tmp

ln -s /tmp /var/tmp

rm -fr /var/lock

ln -s /tmp /var/lock

3, lehetoleg a devel cuccokat nem felrakni a gepre

Es persze az mar csak finomsag, hogy ahol lehet a szolgaltatasokat kulon rakni, hogy nem az useren fusson.

Amugy szerintetek a noexec mennyire jatszhato ki libekkel valo inditassal,mert amennyire en probalkoztam nekem nemigazan mukodott (mar amennyire vissza tudok emlekezni ra:)).

Egyebkent pedig make-kpkg rulz.

Ysolt

Eredmeny:

user:~> /lib/ld-linux.so.2 ~/a.out

Segmentation fault

user:~> uname -a

Linux user 2.4.22-grsec #1 Fri Sep 5 15:10:48 CEST 2003 i686 unknown

user:~>

grsec: From xxx.xxx.xxx.xxx: signal 11 sent to /lib/ld-2.2.5.so[ld-linux.so.2:32190] uid/euid:1657/1657 gid/egid:110/110, parent /bin/tcsh[tcsh:8791] uid/euid:1657/1657 gid/egid:110/110

Egyebkent meg a felmountoltam execre a tmp-t es onnan futtattam akkor sajni resetelte a gepet.

Ysolt

( samson | 2003. 12. 02., k – 10:02 )

>>Az exploit közkézen forog

Annyira nagyon nem kerestem, de elso nekifutasra nem talaltam exploitot.

Lehet, hogy ?belterjesen? terjed?

( WoOh | 2003. 12. 02., k – 11:25 )

Nem tudja valaki, hogy a grsec patch vedelmet nyujt-e ellene?

( Gabucino | 2003. 12. 02., k – 12:50 )

A vulnerability fix patchre adjon vki URL-t, mert a 2.4.23-ba uj VM+OOM kerult, es tortenetesen fos.

Thx.

http://forums.grsecurity.net/viewtopic.php?t=611

"the short and bad news is that you are most likely not protected, this bug seems to give complete access to kernel memory and can therefore circumvent any kernel based mechanism. apply the fix or upgrade to 2.4.23 if you haven't done so yet."

( nevergone v | 2003. 12. 02., k – 13:35 )

Nos... most, hogy megvan a hiba, lesznek végre frissítések...?

( trey | 2003. 12. 02., k – 15:00 )

Sajnos ismet bebizonyosodott, hogy Tosatti alkalmatlan a karbantartoi posztra. Sokan kifogasoltak, hogy miert ilyen hosszu a kiadasi idoszak az egyes stabil kernelek kozott. Tobben mondtak, hogy lehetne surubben kiadni a kritikus javitasokat.

Szeptember 28-an a 2.6.0-test6-ban mar benne volt a javitas. Illett volna a stabil kernel hazatajan is korulnezni.

Ebben az eseten mar oktober 10-en ismert volt a do_brk() fuggveny hibaja.

Pontosabban a 2.4.23-pre7 changelogja alapjan mar akkor megvolt a javitas a hatarellenorzesre:

[...]

:

o Fix missing part of Centrino cache detection change

o Add TASK_SIZE check to do_brk()

[...]

Ha Tosatti akkor felhivja a figyelmet arra, hogy ez a kritikus hiba, akkor valoszinuleg nem torik meg a Debian szervereket sem.

Alan Cox hianya nagyon erzodik a 2.4-es kernelsorozaton. Tosatti elhanyagolta a 2.4-et. Remelem, hogy tobbet nem lesz ennyire fiatal karbantartoja a Linux kernelnek.

A sid-hez nincs hivatalos biztonsagi frissites. De ettol meg senki nem gatol meg ebben:

1.) wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.23.tar.bz2

2.) konfigural

3.) leforgat

4.) reboot

5.) happy

vagy

1.) wget http://security.debian.org/pool/updates/main/k/kernel-image-2.4.18-1-i386/kernel-image-2.4.18-1-i386_2.4.18-12.tar.gz

2.) ugyanaz mit feljebb

vagy

1.) http://security.debian.org/pool/updates/main/k/kernel-image-2.4.18-1-i386/kernel-image-2.4.18-1-k7_2.4.18-12_i386.deb

2.) dpkg -i kernel-image-2.4.18-1-k7_2.4.18-12_i386.deb

Azt hiszem van alternativa.