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 [EMAIL PROTECTED] 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
