Czy łatwiej wykorzystać otwarty kod?

2010-06-09 17:35

Gdy tylko pojawił się termin "otwarty kod źródłowy" natychmiast rozpoczęła się dyskusja, które rozwiązania są bezpieczniejsze: te o zamkniętym czy otwartym kodzie. Gdy wydawało się że dyskusja ta w końcu została zepchnięta na dalszy plan (teraz modny jest temat cloud computing) pojawiła się praca "An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software" autorstwa Sama Ransbotham prezentowana podczas "Workshop on the economic of information security". Niewątpliwie bezpieczeństwo informacji jest ściśle powiązane z ekonomią. Doskonałym przykładem może być kryptografia gdzie często bezpieczeństwo zakłada się na podstawie szacunku potrzebnego czasu, mocy obliczeniowej i energii. Każdy z tych elementów ma oczywisty związek z ekonomią. Generalnie nieekonomicznych ataków nikt nie przeprowadza. Dlatego taki raport prezentowany w powyższym kontekście wydał nam się bardzo interesujący.

Raport oceńcie sami. Na kilku listach dyskusyjnych pojawiły się cenne spostrzeżenia na temat tej pracy więc nie warto się powtarzać. Z drugiej jednak strony bardzo często podczas realizowania projektu, zadaje nam się pytanie od którego cały niniejszy wywód się zaczął. Pomyśleliśmy wtedy, że warto publicznie przedstawić kilka faktów oraz pogląd AVET INS na ten temat (niekoniecznie związanych ze wspomnianą wcześniej pracą).

  1. Produkcja bezpiecznego oprogramowania nie jest procesem trywialnym i wymaga odpowiedniego ustawienia. Proces tworzenia bezpiecznego kodu jest taki sam niezależnie od tego czy się go później udostępnia czy też nie.
  2. Niedoświadczeni i niewyedukowania programiści zawsze wyprodukują niebezpieczny kod niezależnie czy pracują nad projektem open-source czy nad rozwiązaniem komercyjnym.
  3. Rozwiązania dedykowane do wewnętrznego użytku często są bardziej niebezpieczne gdyż wymagania bezpieczeństwa łatwo się w nich ignoruje.
  4. Analizowanie kodu źródłowego – zwłaszcza pod kątem bardziej skomplikowanych podatności związanych na przykład ze stanem – jest niezwykle czasochłonne a więc może być także nieopłacalne z ekonomicznego punktu widzenia
  5. Identyfikacja podatności w obiektach binarnych za pomocą fuzzingu jest rozwiązaniem w którym wiele elementów procesu da się zautomatyzować
  6. W przypadku tworzenie exploitów dla klasycznych błędów opartych na przepełnieniu, dostęp do kodu źródłowego jest drugorzędny ponieważ i tak operuje się na ramce stosu czy strukturze sterty. Z poziomu kodu źródłowego te elementy są niewidoczne, chyba że akurat mamy do czynienia z asemblerem (ale nawet wtedy, w przypadku platformy Win32/64 makra skutecznie potrafią ukryć elementy nas interesujące).
  7. Jeśli ktoś zakłada że proces kompilacji utrzyma coś w sekrecie to bardzo się myli. Podczas pisania kodu zalecamy przyjąć tą samą taktykę co w przypadku projektowania rozwiązań kryptograficznych: to nie zamkniętość rozwiązania i brak o nim wiedzy decyduje o jego bezpieczeństwie lecz otwartość i siła zastosowanych algorytmów.

Z powyższej której charakterystyki wynika, że więcej błędów mają te aplikacje, podczas tworzenia których nie myślano o bezpieczeństwie. Otwartość kodu źródłowego nie ma w tym przypadku żadnego związku. Widać także, że ekonomia poszukiwania i wykorzystania podatności w aplikacjach – ze względu na możliwość zautomatyzowania procesu – wskazuje na aplikacje webowe i obiekty binarne (znów niezależnie od tego czy mamy dostęp do ich kodu). Ostatnim istotnym spostrzeżeniem jest fakt, że wiele technologii wykorzystywanych współcześnie jest opartych o bytecode. Java, .NET czy Python są tutaj doskonałymi przykładami. Dekompilacja w tych przypadkach jest zazwyczaj prosta i automatyczna. Z kolei firma Hex-Rays – producent pakietu IDA Pro – oferuje także zaawansowany dekompilator generujący kod w C. Widać więc, że poziom bezpieczeństwa i koszt wyprodukowania działającego exploita wcale nie musi być związany z dostępem do kodu źródłowego.

Blog

MS SQL Server 2005 Extended Support kończy się 12 kwietnia

Rozszerzone wsparcie dla serwera Microsoft SQL Server 2005 kończy się 12 kwietnia. To ostatni moment aby dokonać migracji do wyższej wersji.

Jeśli tego nie zrobiłeś to AVET INS może wesprzeć ...

2016-03-01 09:00, Czytaj więcej Więcej
Kiedy Flash wyginie?

Flash to jedna z tych technologii, która ma bardzo złą – i w tym wypadku całkowicie zasłużenie – reputację w obszarze bezpieczeństwa. Ta reputacja jest tak zła, że od jakiegoś czasu część ...

2016-02-11 16:45, Czytaj więcej Więcej
Krytyczna podatność w kliencie OpenSSH (CVE-2016-0777, CVE-2016-0778)

Wersje oprogramowania klienckiego OpenSSH w wersjach od 5.4 do 7.1 podatne są na atak umożliwiający wyciek pamięci oraz kradzież kluczy prywatnych. W przypadku, gdy połączenie SSH zostanie przerwane ...

2016-02-01 09:30, Czytaj więcej Więcej
Microsoft ogranicza wsparcie IE tylko do wersji 11

Microsoft przestaje wspierać starsze wersje przeglądarki Internet Explorer. Jedyną wspieraną wersją od dzisiaj jest IE 11 i wyższe. Dla wielu systemów (np. Windows 7) może to oznaczać potrzebę aktualizacji lub ...

2016-01-13 09:00, Czytaj więcej Więcej
SafeNet Day: Szyfrowanie w chmurze - prezentacja

Prezentacja Aleksandra Czarnowskiego z konferencji SafeNet Day na temat Szyfrowanie w chmurze jest już dostępna do pobrania. Zapraszamy do pobrania poniżej:

http://www.avet.com.pl/media/pdf/2015-11-02_Szyfrowanie_w_chmurze.pdf

2015-10-31 10:00, Czytaj więcej Więcej