Powazna dziura w systemie.
Witam.
Ostatnio odnaleziono powazny blad w jadrze systemow linux
chcialbym poinformowac o tym kilku znajomych administratorow takich
systemow.
Otoz wykonanie przez ZWYKLEGO usera krotkiego programu powoduje calkowite
wywrocenie systemu i jedyna droga powrotu do stanu wyjsciowego jest
twardy restart. Problem istnieje podobno jedynie na maszynach klasy i386.
Zeby nie byc goloslownym to informuje, ze wykonalem test na mojej maszynie
linux 2.4.19 + grsecurity, celeron 333@2375 i tekst zakonczyl sie sukcesem
:(( znaczy system padl i kwiknal jedynie kernel panic. W logach NIE
POZOSTAL po tym zaden slad.
Chyba jedynym sladem, ktory moze administratora naprowadzic na sprawce
zamieszania to logi z ssh, tylko, ze w przypadku udostepniania
userom screena sprawa sie znacznie skomplikuje.
Jesli ktos chce przetestowac, to polecam poszukiwania w sieci.
Ja kodu exploita rozprowadzac nie bede.
Niebezpieczenstwo istnieje wylacznie na serwerach udostepniajacych konta
shellowe, i takie serwery powinny jak najszybciej zostac zupgradowane.
Ja w celu unikniecia jakichkolwiek problemow bardziej restrykcyjnie
dobezpieczylem jadro za pomoca grsecurity oraz zalozylem na jadro
2.4.19+grsec latke pobrana z:
http://cvs.pld.org.pl/SOURCES/kernel-2.4-NTfix.patch?rev=1.2
pozdrawiam
--
mirek
p.s. nie wiem jaka jest mozliwosc dobezpieczenia jader serii 2.2.x, byc
moze trzebaby zmodyfikowac latke lub odnalezc odpowiednia w sieci. Ja na
jadra 2.4.19 przeszedlem jakies dwa tygodnie temu.
Cytalem, ze samo posiadanie latki OpenWall nie wystarcza.
Mysle, ze najlepszym doraznym rozwiazaniem moze byc casowa blokada dostepu
do shella, lub uniemozliwienie userom wykonywania jakiegokolwiek
nieaytoryzowanego kodu. Opcja noexec polecenia mount. Niestety jesli damy
noexec jedynie na /home user moze sobie skompilowac program w /tmp ktory
jest zwykle podkatalogiem partycji / a na niej nie mozemy dac noexec.
itd. itd.
p.p.s. info dot. bledu: http://7thguard.net/news.php?id=2381
Reply to: