Dziurawa recydywa
-
- Paweł Krawczyk,
- 17.11.2003
Zmarnowane lata
Wybierając platformę dla swojej aplikacji mającej w perspektywie więcej niż tydzień funkcjonowania, powinno się brać pod uwagę dotychczasowe osiągnięcia programu w zakresie bezpieczeństwa. W takim przypadku Sendmail ani BIND raczej nie pojawią się na krótkiej liście, przynajmniej bez dodatkowych zabezpieczeń. Co roku w każdej z nich jest wykrywanych co najmniej kilka poważnych luk krytycznych z punktu widzenia bezpieczeństwa. Z drugiej strony, to zastanawiające, że aktualną wersję pakietu BIND 4 dzieli od pierwszej edycji 9, prawie 10 lat, a więc niemal wieczność.
Pytanie o przyczyny nie kończących się problemów wydaje się jak najbardziej na miejscu. Większość "dziurawych" aplikacji ma wspólne dwie cechy. Pierwsza z nich to skłonność do łączenia zbyt wielu funkcjonalności w ramach jednego narzędzia - dolegliwością "kombajnów" realizujących imponującą liczbę funkcji jest zwykle równie imponująca liczba błędów. Im więcej funkcji wykonuje program, tym trudniej zachować separację przywilejów, będącą podstawowym warunkiem bezpieczeństwa jakiegokolwiek systemu komputerowego. Druga cecha wspólna to nagminne wykorzystanie w nowych wersjach starego kodu, napisanego jeszcze w czasach, gdy problemy z bezpieczeństwem nie były tak poważne.
Z błędów popełnionych w systemie Send-mail wnioski wyciągneli autorzy nowoczesnych serwerów pocztowych Postfix i Qmail. Ich konstrukcja jest zaprzeczeniem tego, czym w sensie architektury są protoplaści - składają się z wielu małych modułów wykonujących ściśle określone zadania, np. przyjmowanie połączeń SMTP, wysyłanie poczty, skanowanie kolejki itd. Uprawnienia poszczególnych modułów są ściśle powiązane z zakresem pełnionych funkcji. Ponadto w obu programach można znaleźć dobrze przemyślane i zaprojektowane pod kątem wymogów bezpieczeństwa funkcje biblioteczne.
Rezultat jest taki, że serwery pocztowe wykorzystujące oprogramowanie Postfix lub Qmail uruchomione kilka lat temu działają po dziś dzień bez problemów z bezpieczeństwem. Odejście od złej praktyki w dziedzinie architektury jest jednym z kluczowych warunków poprawy odporności oprogramowania na ataki.
Ku resocjalizacji
Konkludując, ostatnich kilka lat pokazuje, że samo łatanie dziur, nawet przy najlepszej dostępności poprawek, jest niewystarczające - nieodzowna jest poprawa jakości oprogramowania. Cel ten można osiągnąć dwojako.
Po pierwsze, przez edukację i uświadamianie przede wszystkim programistów, ale także administratorów i użytkowników. Druga metoda polega na wbudowaniu mechanizmów bezpieczeństwa do systemów na możliwie wczesnym etapie. Możliwości jest kilka, jak choćby kompilatory z wbudowanymi mechanizmami do ochrony stosu, np. ProPolice dla kompilatora GNU C/C++ czy flaga GS w kompilatorze Microsoftu. Rozwiązanie takie zastosowano w niektórych dystrybucjach Linuxa (np. Immunix) oraz w Windows Server 2003.
Równolegle trzeba stosować mechanizmy i techniki zabezpieczające, działające na poziomie systemu operacyjnego w sposób przezroczysty dla aplikacji. W ostatnich latach dzięki projektom, takim jak PaX, nastąpił na tym polu ogromny postęp. Są one oferowane domyślnie w niektórych dystrybucjach Linuxa i OpenBSD, jednak realnych efektów ich zastosowania nie zauważymy dopóty, dopóki nie staną się one częścią dystrybucji najbardziej rozpowszechnionych.
Większość problemów z bezpieczeństwem wynika z rynkowej dominacji produktów, które pod względem bezpieczeństwa pozostawiają dużo do życzenia. Bezpośrednią przyczyną obecnych epidemii wirusów są miliony domowych komputerów wykorzystujące "stare" wersje systemów Windows (95/98/Me) mające z bezpieczeństwem niewiele wspólnego. Do tego dochodzą "nieuszczelnione" wersje klientów pocztowych Outlook.
Dążąc do uczynienia oprogramowania bardziej przyjaznym dla użytkowników, Microsoft wpadł w swego rodzaju pułapkę. Wygoda polegająca na automatycznym uruchamianiu wszelkich załączników i makr była, jak się okazało, przede wszystkim przysługą dla autorów wirusów i koni trojańskich, co najdobitniej udowodniły epidemie Code Red i Nimda. Na szczęście, ostatnia wersja Microsoft Outlook (2003) jest wyposażona w liczne zabezpieczenia i tak skonfigurowana domyślnie, że żadne nowe wirusy nie powinny być dla niej zagrożeniem. Można więc liczyć, że w ciągu kilku lat epidemie "wirusów outlookowych" wygasną.
Nie lepiej jest po stronie serwerowej: serwer WWW Microsoft IIS, serwer pocztowy Sendmail oraz serwer DNS BIND to główni bohaterowie największych "afer" z bezpieczeństwem w ostatnich latach. W tym roku pojawiła się nowa opcja - wirusy rozprzestrzeniające się bez pośrednictwa serwerów pocztowych, a wykorzystujące lukę w usługach RPC systemów Windows.
Paweł Krawczyk jest inżynierem w firmie ABA w Krakowie.
