Dyskusja o bezpieczeństwie jądra

Specjalistów martwi to o tyle, że problem dotyczy najnowszego jądra, które dopiero ma zostać rozpowszechnione.

Nie widzę w tym problemu to zmartwień. Wystarczy odwołać publikację/udostepnienie kodu źródłowego jądra. Prawdziwym powodem do zmartwień byłoby raczej wykrycie krytycznej dziury po udostępnieniu kodu i powszechnej aktualizacji jądra po stronie użytkowników.

Sprawdzanie kodu nie wykazuje żadnych błędów, jednak jeśli do kompilacji jądra użyto GCC z włączonymi funkcjami optymalizacyjnymi, to usunie on kilka linijek kodu chroniących przed wystąpieniem błędu.

Dla mnie wygląda to raczej na błąd optymalizacji kompilatora, ale nie będę się sprzeczał z mądrzejszymi.

Zgadzam się z mikroosem - wszystko, co twórcy muszą zrobić (poza rozwiązaniem problemu) to opóźnić wydanie nowego jądra.

No właśnie o to się też sprzeczają. Czy błąd jest w kompilatorze czy w jądrze. Pytanie jest też, co z nim zrobić, bo z jednej strony jest poważny, z drugiej - trzeba się sporo nagimnastykować, żeby go wykorzystać. No i pojawiły się też zarzuty, że o błędzie wiadomo od baardzo dawna, ale dotychczas nic z nim nie zrobiono. Tak czy inaczej - ciekawy problem.

No właśnie o to się też sprzeczają. Czy błąd jest w kompilatorze czy w jądrze. Pytanie jest też, co z nim zrobić, bo z jednej strony jest poważny, z drugiej - trzeba się sporo nagimnastykować, żeby go wykorzystać.

Akurat to jest łatwe do rozstrzygnięcia - istnieje sporo RÓŻNYCH kompilatorów c/c++, wystarczy jądro skompilować na innym kompilatorze i będzie jasne, kto zawinił.

Problem jest ciekawy z nieco innej przyczyny - zakładając, że załatany zostanie jedynie gcc jądra zbudowane starszą wersją kompilatora (wszyscy* wiemy, jak to jest z zabawą w ciągłe aktualizowanie oprogramowania) będą nadal podatne na tę lukę. Wydaje mi się, że właśnie dlatego twórcy jądra, nawet jeżeli wina leży po stronie GCC główkują, jak problem skrzętnie obejść.

*wypowiadam się sam za siebie (Usera okienek), z nadzieją, że znajdzie się choć 10 innych internautów, którzy także nie zawsze są na bieżąco z aktualizacjami oprogramowania.(czasami niedopatrzenie, czasami wynik świadomego wyboru)

Błąd jest w jądrze. Kompilator zgodnie z życzeniem zoptymalizował kod przez usunięcie niepotrzebnego sprawdzania wskaźnika. Konkretnie chodzi o taki fragment kodu:

// Tu jest założenie, że tun jest prawidłowym wskaźnikiem
struct sock *sk = tun->sk;
…
// A chwilę potem jest to sprawdzane
if (!tun) return POLLERR;

Kompilator założył, że skoro wcześniej się z tego wskaźnika skorzystało, to nie trzeba go potem już sprawdzać. Normalnie przy próbie odwołania do nieprawidłowego wskaźnika, powinien wystąpić błąd i funkcja dalej się nie wykona, ale gdy jest zainstalowane SELinux, to błędu nie będzie, funkcja będzie się wykonywać dalej, ale już z usuniętym zabezpieczeniem.

Rozwiązaniem jest przeniesienie fragmentu sprawdzającego czy wskaźnik jest prawidłowy na sam początek, zanim skorzysta się z niego. Czyli tak jak każdy dobry programista by zrobił

Szczegóły: http://isc.sans.org/diary.html?storyid=6820

Huh, faktycznie. Toż to podręcznikowy błąd podczas zabawy ze wskaźnikami.