Absolutny brak pewności

Praktyka dowodzi, że dostępność kodu źródłowego wpływa na poprawę jakości oprogramowania. Nie oznacza to jednak, że oprogramowanie open source jest wolne od wad i luk w zabezpieczeniach.

Praktyka dowodzi, że dostępność kodu źródłowego wpływa na poprawę jakości oprogramowania. Nie oznacza to jednak, że oprogramowanie open source jest wolne od wad i luk w zabezpieczeniach.

Oprogramowanie rozwijane na zasadach open source wielokrotnie potwierdziło swoją wysoką jakość. Przynajmniej w części jest ona rezultatem tego, że kod tworzony w ramach projektów open source jest oceniany przez liczne grono niezależnych specjalistów. Pisać niechlujnie zwyczajnie nie wypada, a poza tym, im więcej oceniających, tym mniejsze szanse na pozostawienie w kodzie poważnego błędu.

Efekt działania kultury otwartego kodu bywa przy wielu okazjach porównywany z oprogramowaniem komercyjnym - głównie produktami Microsoftu. Patrząc wstecz, trudno nie zauważyć, że liczba krytycznych błędów w rozwiązaniach open source jest zdecydowanie mniejsza niż w rozwiązaniach rodem z Redmond. Jednak wywodzenie z tego faktu ogólnej tezy, że oprogramowanie dostępne wraz z kodem źródłowym (czy też w formie kodu źródłowego) jest zawsze bezpieczniejsze niż oprogramowanie komercyjne, jest co najmniej ryzykowne.

Czując się dyżurnym chłopcem do bicia, Microsoft nie pozostaje środowisku open source dłużny. Przy każdej nadarzającej się okazji stara się przekonywać, że dostępność kodu źródłowego to dla bezpieczeństwa systemów i aplikacji nic innego jak katastrofa. Nie jest to pogląd zupełnie bezpodstawny, choć w swej wymowie raczej mocno przesadzony. Od lat 70. wiadomo że sprytna modyfikacja kompilatora pozwala uczynić każdy program powstały z jego użyciem podatny na zdalne przejęcie kontroli. Tak się składa, że duża część oprogramowania open source jest kompilowana przy użyciu kompilatorów GCC - również będących produktami open source.

Niezależnie od tego, łatwy dostęp do kodu dużej liczby osób to magnes dla tych, którzy chcieliby w niezauważony sposób "doposażyć" go kodem konia trojańskiego. Nie jest to scenariusz wyssany z palca - w ub.r. kilkakrotnie włamywano się na serwery, na których były przechowywane kody źródłowe różnych projektów open source. Wystarczy wspomnieć głośny przypadek ujawnienia konia trojańskiego w kodzie OpenSSH. Pół biedy, gdy, tak jak w przypadku niedawnego włamania na serwery projektu Debian, sprawa wyszła na jaw prawie natychmiast. Nie wszyscy mają jednak tyle szczęścia - fakt włamania na serwery projektu GNU wykryto w sierpniu ub.r., podczas gdy miało ono miejsce w... kwietniu 2003 r. Przez 4 miesiące tysiące ludzi pobierały i instalowały oprogramowanie, mając do niego zaufanie.

Dla równowagi przypomnijmy, we wcześniejszych latach wielokrotnie włamywano się także do serwerów Microsoftu. Co tak naprawdę wpadło w ręce włamywaczy, zapewne na zawsze pozostanie słodką tajemnicą producenta Windows.

Kryptolodzy przykład dali

A zatem, czy otwartość, jawność, weryfikowalność służy bezpieczeństwu informacji, czy też nie? To pytanie zadają sobie codziennie tysiące administratorów na całym świecie. Co ciekawe, świat cywilnej kryptografii dawno już rozwiązał ten dylemat.

Wszystkie cywilne algorytmy kryptograficzne powstają w sposób otwarty. Tak było z najpopularniejszym obecnie algorytmem 3DES, jak również ze stanowiącym jego następcę szyfrem AES. Przed zatwierdzeniem jako oficjalne (dodajmy: w pełni otwarte) standardy, oba szyfry przeszły długą ścieżkę publicznej weryfikacji. Jakoś nie widać, aby fakt ten powstrzymywał banki na całym świecie od udostępniania usług w Internecie. Każdy z wykorzystywanych przez nie bezpiecznych protokołów, takich jak IPsec, SSL czy TLS, opiera się na standardowych szyfrach 3DES lub AES. Na 3DES opiera się także wykorzystywany przez polskie służby specjalne i wojsko NASz (Narodowy Algorytm Szyfrujący).

Stosowanie tajnych zabezpieczeń w implementacjach programowych, zwłaszcza dostępnych dla szerokiego grona użytkowników, jest z założenia rozwiązaniem chybionym. Obecne techniki analizy kodu binarnego (reverse engineering) pozwalają na szybkie odtworzenie zastosowanego algorytmu. Obrazuje to wiele spektakularnych porażek systemów ochrony przed kopiowaniem DRM (Digital Rights Management), takich jak DVD CSS (Content Scrambling System), SDMI (Secure Digital Media Initiative) czy wprowadzony przez Microsoft algorytm DRMv2.

Nawet firmy zajmujące się pisaniem oprogramowania związanego z bezpieczeństwem (Check Point, ISS, Cisco i inni) nie forsują już własnych rozwiązań kryptograficznych, jak niegdyś, lecz podkreślają przywiązanie do otwartych standardów.

Nie kod, lecz dobre praktyki

Wróćmy jednak do kodu. Pogląd, że bezpieczny kod powinien być otwarty, ma bardzo silne umocowanie w praktyce. Doświadczenie pokazuje, że twórca kodu nie jest w stanie wszechstronnie przeanalizować nawet kodu własnego autorstwa, nie mówiąc już o analizie styku jego kodu z kodem pisanym przez innych. Tym bardziej wtedy, gdy jego ilość idzie w setki tysięcy czy nawet miliony linii. Jawność jest więc sposobem na zmniejszenie ryzyka - czynnika nieodłącznie towarzyszącego systemom informatycznym.

Otwartość kodu ma pozytywny wpływ na bezpieczeństwo aplikacji, gdyż wymusza na programiście trzymanie się standardów, zamiast stosowania własnych "sprytnych" algorytmów. Standardy umożliwiają niezależnym ekspertom wgląd w kod i analizę przyjętych rozwiązań i wprowadzają imienną odpowiedzialność za ewentualne błędy, co odgrywa ważną rolę dyscyplinującą. Otwartość kodu jako taka podnosi więc jego jakość, a więc pośrednio także bezpieczeństwo.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200