To, co bezpieczeństwu oprogramowania może szkodzić, to słabe zabezpieczenia repozytoriów lub wadliwe procedury zatwierdzania zmian w kodzie. Dotyczy to zarówno projektów komercyjnych, jak i open source. Środowisko open source w szczególności musi dopracować się lepszych reguł kontroli przywilejów osób mających istotny wpływ na ostateczną postać kodu. Dotychczasowe radosne stosunki koleżeńskie muszą stać się, być może, bardziej formalne.

Statystyki i interpretacje

Trwająca między środowiskiem open source a Microsoftem wojna na słowa przybiera niekiedy wręcz śmieszne formy, nie przybliżając użytkowników ani na jotę do rozwiązania ich rzeczywistych dylematów.

Na witrynie Microsoftu czytamy np. że "CERT, wiodąca organizacja zajmująca się śledzeniem bezpieczeństwa, w 2002 ogłosiła 5 błędów w Windows, 12 w systemie Red Hat Linux i 12 w Sun Solaris". Wynika z tego, że Windows jest, nie przymierzając, 2,4 razy bezpieczniejszy od Linuxa czy nawet Solarisa! Gdyby tak było, słowa: Slammer czy Blaster kojarzylibyśmy z bohaterami bajek, a nie wirusami zagrażającymi ciągłości działania firm.

Czy ktoś pamięta nazwy wirusów dla Linuxa? Owszem, największa dotychczas epidemia wirusa Slapper objęła w ciągu miesiąca ok. 30 tys. serwerów Apache, wykorzystując lukę w module obsługi SSL. Dla porównania, Slammer zainfekował ok. 500 tys. serwerów w ciągu kilku dni. Ta ponad 15-krotna różnica (pomijając czas) nie jest jedynie kwestią popularności rozwiązań Microsoftu - serwery z Apache stanowią w Internecie większość. Nie oznacza to, że serwery WWW czy inne aplikacje działające na systemie Linux i innych systemach open source są automatycznie bezpieczne. Taka teza jest równie ezoteryczna jak obietnice wiecznych wakacji dla administratorów, którymi kusi Microsoft.

Luki umożliwiające przepełnienie bufora i wykonanie nieautoryzowanego kodu pojawiają się zarówno w produktach komercyjnych, jak i rozwiązaniach open source. W ub.r. Microsoft i jego klienci otrzymali cięgi (w postaci wirusa MSBlaster) w wyniku wykrycia przez polską grupę LSD luki w bibliotece obsługującej zdalne wywołania procedur (RPC). Oberwało się także Linuxowi - dwa poważne błędy w module zarządzania pamięcią zaowocowały stworzeniem kodu umożliwiającego uzyskanie praw administratora przez dowolnego zalogowanego do systemu użytkownika. Notabene, tę lukę także odkryli Polacy - tym razem z grupy iSEC.

Oba powyższe przykłady pokazują, że błędy i luki w zabezpieczeniach mogą się pojawić w dowolnym oprogramowaniu - w praktyce nie zapobiegają im ani praktykowany przez środowisko open source zdecentralizowany, grupowy model utrzymania jakości, ani komercyjnie zorganizowana produkcja oprogramowania. Proszę zauważyć, że w obu przypadkach błędy były zlokalizowane w kluczowych, niskopoziomowych częściach systemów, które powinny być (i zapewne były) dokładnie testowane. Opatrzność chciała, zdaje się, dać w ten sposób obu środowiskom lekcję pokory.

Pojedynek na funkcje

O bezpieczeństwie świadczą nie tylko jakość kodu, ale także funkcjonalność. W systemie Linux firewall jest integralną częścią systemu operacyjnego od ok. 1995 r. Firewall o niepozornej nazwie iptables, dostępny w aktualnych wersjach Linuxa, jest funkcjonalnie porównywalny z najlepszymi rozwiązaniami komercyjnymi, takimi jak Check Point Firewall-1. W Windows ograniczony funkcjonalnie firewall ICF pojawił się sześć lat później i do tej pory jego funkcjonalność jest bardzo wąska.

Inny przykład. Pierwsze techniki ochrony przed wykonywaniem wrogiego kodu w systemie operacyjnym (system stack protection) opracowano dla Linuxa ponad 7 lat temu, niedługo po tym, jak ataki tego typu zostały opisane w magazynie Phrack. Wkrótce pojawiły się także wersje dla Solarisa i systemów z serii BSD. Dla porównania, techniki zabezpieczeń utrudniające wykonywanie wrogiego kodu w systemie pojawiły się w Windows dopiero w ub.r. i to nie z inicjatywy jego producenta, lecz jako niezależny produkt komercyjny. Jako immanentna część systemu operacyjnego ochrona stosu pojawi się dopiero w tym roku, a i to tylko dla tych, którzy zakupią komputery z najnowszymi procesorami AMD i Intela.

W systemie Linux administrator jest ograniczony tylko własną pomysłowością, można więc powiedzieć, że nad innowacjami w nim pracuje cały świat. Być może dlatego właśnie rozpoczęty niedawno przez amerykańską Agencję Bezpieczeństwa Narodowego (NSA) nosi nazwę Security Enhanced Linux, a nie Security Enhanced Windows.

Zapraszam do dyskusji.

Paweł Krawczyk jest niezależnym specjalistą współpracującym z firmami ABA i SecuRing.