9:54
15/4/2014

O błędach programistów i testowaniu oprogramowania w kontekście Heartbleed

Autorem poniższego artykułu jest Janusz Nawrat, który na łamach Niebezpiecznika opublikował już cieszący się dużą popularnością artykuł–przewodnik dotyczący obsługi incydentu bezpieczeństwa informacji.

Do napisania tego komentarza skłoniła mnie dyskusja na temat ujawnionego niedawno krytycznego błędu w oprogramowaniu OpenSSL (Heartbleed bug), który skutkuje wyciekiem pamięci z podatnych maszyn wykorzystujących obarczony błędem kod. W szczególności chciałbym skomentować jeden z wątków tej dyskusji: czy służby amerykańskie wiedziały o błędzie wcześniej i czy wykorzystywały go do celów inwigilacyjnych.

Zacznijmy jednak od refleksji natury ogólnej, by potem przejść do finalnych konkluzji. Niepodlegającym dyskusji faktem jest to, że o bezpieczeństwie systemów decyduje w krytycznym stopniu kod oprogramowania. Zaś jego rozmiar, tempo rozwoju, złożoność i skala wykorzystania, połączona ze zróżnicowaną jakością tak samego kodu, jak i procesów oraz narzędzi jego wytwarzania sprawia, że żadna organizacja na świecie nigdy nie zapanuje w pełni nad błędami developerskimi, nie wyłączając oczywiście tych, z których mogą wynikać problemy z bezpieczeństwem. W pełni bezpieczny system jest niestety – czy tego chcemy, czy też nie – niczym więcej, tylko mitem.

Ktoś kiedyś powiedział, w tonie może nieco zbyt makabrycznego sarkazmu, że gdyby samochody były wytwarzane w tak krótkim cyklu i pod taką presją wymagań rynku jak komputery, to Rolls-Royce powinien dziś kosztować 100 dolarów, przejeżdżać milion kilometrów na pełnym baku paliwa i… eksplodować raz do roku, zabijając wszystkich pasażerów. Choć ta analogia wydaje się być z gatunku „z gruba ciosanych”, to tkwi w niej iskierka prawdy, przynajmniej odnośnie tego, że błędy w oprogramowaniu były, są i będą obecne.

Wielu ludziom od lat nieodmiennie pojawia się w głowach pytanie: dlaczego nie jest możliwe wyeliminowanie wszystkich błędów bezpieczeństwa w oprogramowaniu?

Otóż, po pierwsze, ogromny rozmiar kodu w skomplikowanych systemach utrudnia analizę, nawet jeśli jest ona wspomagana narzędziami automatyzującymi ten proces.

Nie od dziś wiadomo, że złożoność jest wrogiem bezpieczeństwa. Z publikowanych w Internecie statystyk wynika, że na każde 1000 linii kodu źródłowego przypada średnio 5 błędów. Na przykład, sam system operacyjny Windows 7 liczy sobie około 120 milionów linii kodu. Zawiera więc potencjalnie 600 000 błędów. Jeśli przyjmiemy, a istnieją racjonalne podstawy do takiego założenia, że co najmniej 10 procent z nich może skutkować naruszeniem bezpieczeństwa, to mamy w systemie 60 000 (!) różnego rodzaju luk. Część z nich to błędy już wykryte i „załatane” pozostała część, to błędy czekające na wykrycie, czyli swego rodzaju bomba z opóźnionym zapłonem. Dotyczy to – rzecz jasna – każdego rodzaju oprogramowania, nie tylko oprogramowania systemów operacyjnych i – oczywiście – nie tylko produktów firmy Microsoft.

Po drugie, testerzy bezpieczeństwa mają najczęściej ograniczony dostęp wyłącznie do skompilowanej wersji oprogramowania (nie posiadają wglądu w kod źródłowy, poprzez analizę którego mogliby potencjalnie zidentyfikować wszystkie błędy wynikające ze złamania standardów i dobrych praktyk bezpiecznego programowania). W takiej sytuacji, badane oprogramowanie jest po prostu dla testera rodzajem czarnej skrzynki. Ma on, co prawda, pewne możliwości uchylenia rąbka owej tajemnicy skrywanej w jej wnętrzu i zaglądnięcia tam przy pomocy metod i narzędzi inżynierii wstecznej (dekompilacja kodu i śledzenie jego uruchamiania), ale nie zawsze jest to możliwe (zabezpieczenia przed dekompilacją i śledzeniem wykonania kodu (debuggingiem)), nie zawsze jest to legalne, za to prawie zawsze jest to ogromnie czaso- i pracochłonne. Zaś badanie bezpieczeństwa metodą czarnej skrzynki przez obserwowanie zachowania systemu w odpowiedzi na różne ekstremalne działania testera, podobne do tych, które wykonuje intruz kierujący się w swym postępowaniu zamiarem złamania zabezpieczeń systemu, nie zawsze daje pełen obraz. Niektóre błędy bowiem ujawniają się w bardzo specyficznych sytuacjach, na przykład podczas interakcji z innymi systemami, czy – przykładowo – z obcym kodem bibliotek programistycznych, zewnętrznym oprogramowaniem serwerów aplikacyjnych, systemów bazodanowych, oprogramowaniem middleware czy oprogramowaniem systemów operacyjnych. Takich właśnie błędów może nie uwzględniać żaden ze scenariuszy testów, chyba że test bezpieczeństwa jest zaplanowany na kilka lat. Nawiasem mówiąc, taki test kosztowałby pewnie majątek :-).

Zawsze więc pozostaje w systemie jakiś obszar niezbadany. Stąd też wynika to, że podatności w systemach na całym świecie są stale wykrywane i ten proces zdaje się nie mieć końca, mimo ogromnego wzrostu wiedzy o bezpieczeństwie wśród developerów i ekspertów od tej tematyki, mimo wielkiej skuteczności narzędzi składających się na warsztat pracy testera bezpieczeństwa, mimo wielkiego postępu w dziedzinie standardów bezpiecznego tworzenia aplikacji, czy wreszcie mimo pojawienia się na rynku bardzo dobrych narzędzi do tworzenia dużo bezpieczniejszego niż niegdyś oprogramowania, które same już, w wielu sytuacjach, potrafią wymusić na kodzie aplikacji jego zgodność z podstawowymi zasadami bezpieczeństwa (na przykład w dziedzinie przydziału i zwalniania pamięci dla procesów i struktur danych).

Nie odkryję Ameryki stwierdzeniem, że nie istnieje na świecie w pełni bezpieczny system, ale – co bardzo istotne – istnieją gorsze lub lepsze metody zarządzania jego bezpieczeństwem. Jeśli ktoś twierdzi inaczej, to śmiem twierdzić, że szerokim łukiem mija się z prawdą.

Wracając zaś do sprawy wykorzystywania przez służby amerykańskie błędów w kodzie, to – zaryzykuję stwierdzenie – mają one do dyspozycji o wiele więcej, zakładam też, że dużo lepszych i być może prostszych sposobów na przełamywanie bezpieczeństwa internetowych systemów. Jestem też przekonany, że tego rodzaju luki jak Heartbleed jeszcze wielokrotnie podniosą nam poziom adrenaliny. Ja jednak patrzę na tę sprawę z większym optymizmem, będąc przekonany, że tego rodzaju incydenty są jak zimny prysznic dla decydentów i dysponentów budżetów w instytucjach komercyjnych, którzy przez to skłonni są większą atencją obdarzyć kwestie zabezpieczeń systemów i „sypnąć” obfitszymi środkami na bezpieczeństwo.

Autorem powyższego artykułu jest Janusz Nawrat, który na łamach Niebezpiecznika opublikował już cieszący się dużą popularnością artykuł–przewodnik dotyczący obsługi incydentu bezpieczeństwa informacji.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

44 komentarzy

Dodaj komentarz
  1. problemem jest też sposób łatania błędów: często zamiast porządnie przepisać problematyczny fragment kodu rozwija się go do set dodatkowych linii, co daje dodatkowy 1-2 potencjalne błędy
    oczywiście optymistycznym założeniem jest, że łataliśmy błąd krytyczny, a te 2 takie nie będą, a samo rozwiązanie jest tymczasowe
    jednak o ile błędy niekoniecznie będą krytyczne, to wiemy jak to jest z tymczasowymi rozwiązaniami

    • Tak to prawda. Niezmiernie ważne jest, by bezpieczeństwo wbudować w cykl rozwoju systemów, zamiast przypominać sobie o nim dopiero przed produkcyjnym wdrożeniem oprogramowania. W pełnym cyklu SDLC jest odpowiedni czas na przegląd i dobezpieczenie kodu, bo potem często jest to trudne albo bardzo kosztowne.

  2. Jak doszło do odkrycia błędu Heartbleed, przez testy środowiskowe czy przez analizę kodu źródłowego?

    • Jedno i drugie jest ważne. Testy kodu źródłowego nie zidentyfikują podatności wynikających ze złej implementacji lub “słabej” konfiguracji aplikacji, albo luk w interfejsach komunikacji z jej szeroko pojętym środowiskiem (choćby middleware, system operacyjny, systemy bazodanowe, serwery aplikacyjne, infrastruktura sieciowa itp.).

  3. Pytanie: Czy da się zablokować od strony klienta serwery podatne na taki wyciek Heartbleed?

    • Wyobrażam sobie, że byłoby to dość proste do zrobienia metodami rodem z badania reputacji stron WWW. W sumie nawet można pokusić się o napisanie wtyczki do przeglądarki. Piszemy? :-)

    • jasne, można by, ale co to da?
      Jeśli próbujesz się dostać do serwera któremu pamięć wycieka do internetu, i pewnie tam masz własne konto i dane, to jedynie odrobinę obniżasz prawdopodobieństwo że twoje dane będą akurat w pamięci. Ale co z tego, jeśli dane które umożliwiają PEŁEN dostęp do serwera i bazy danych na nim znalezionych są nadal tak samo zagrożone.

    • @RooTer: Lepsze wczesne ostrzeganie niż nic. Oczywiście, to o czym piszesz jest problemem, bo kiedy masz konto na podatnym serwerze i powierzyłeś jakiemuś serwisowi dane o swojej karcie płatniczej, to robi się niewesoło. Ale mając wtyczkę w przeglądarce, która ostrzega przed podatnym serwerem, nie założysz tam konta i to już jest korzyść.
      Poza tym taka wtyczka mogłaby zostać napisana tak, aby dało się ja sparametryzować pod kątem wykrywania innych podatności (choćby CSRF albo XSS).

  4. Ani słowa o OpenBSD ;)

    • OpenBSD właśnie bawi się w cyfrową wycinankę i wywala sporo niepotrzebnych rzeczy z OpenSSLa lobste.rs/s/3utipo/openbsd_has_started_a_massive_strip-down_and_cleanup_of_openssl

    • Ano… sporo (dobrego) dałoby się powiedzieć ;-)

  5. Też o tym pisałem w 2009 roku http://ipsec.pl/kryptografia/2009/jak-nie-regulowac-rynku-oprogramowania-gwarancje-na-oprogramowanie.html Aczkolwiek OpenSSL i parę innych projektów powoli stało się częścią tzw. infrastruktury krytycznej i stosowanie wobec nich zasad rynku konsumenckiego czy open-source jest błędem. Głównie po stronie korporacji, które z tych projektów korzystają, nie zasilając ich równocześnie kasą i kompetencjami pozwalającymi na zapewnienie jakości oczekiwanej od kodu tej klasy.

    • Bardzo dobry tekst.

  6. There are no coincidences, everything happens for a reason!

    • Sometimes reason being: too much work and not enough coffee (rarely sleep) :P

  7. OpenTLS ;)

  8. Świetny artykuł, choć optymizm Autora wydaje mi się przesadny – w ostatnim akapicie
    użyłbym raczej sformułowań w rodzaju “powinny być jak zimny prysznic” zamiast “są jak
    zimny prysznic” :-(
    Nagminnym zjawiskiem u dostawców software wydaje mi się rezygnacja ze zlecania
    inspekcji kodu niezależnym od twórców zespołom (autor zazwyczaj widzi to, co chciał
    napisać a nie to, co jest napisane) oraz nieegzekwowanie lub zgoła nieformułowanie
    obowiązku tworzenia kodu defensywnego. U podstaw leży zapewne preferowanie przez
    rynek tzw. jakości ekonomicznie uzasadnionej:
    jeżeli prawdopodobieństwo awarii źle zaprojektowanej blokady kierownicy, pomnożone
    przez liczbę posiadających ją aut i średnią wysokość wypłacanego spadkobiercom
    szczęśliwego posiadacza odszkodowania nie przekroczy prognozowanych kosztów akcji
    wymiany wadliwych podzespołów, to akcja taka nie odbędzie się.
    Nasze czasy nie sprzyjają staranności i technologiom w rodzaju trwającego miesiącami
    tworzenia miecza katana, dziwerowej lufy etc. :-(

  9. Linuks + hasła w plain text i jestem bezpieczny.

  10. Nie rozumiem, jak można przez przypadek napisać program, który pyta o długość danych, rezerwuje dobrą ilość pamięci (tzn. sam sprawdza, ile danych odebrał, nie słucha się użytkownika) na nie, i odsyła tyle danych z RAMu, ile wcześniej podał użytkownik.

  11. Blad znany juz od okolo 1,5 roku ,wielu z nas z niego kozystalo,a przez jednego glupka ktory opublikowal wszystko poszlo w *****.
    Teraz przez rozglos cala gimbaza zacznie sie lansowac na hackerow.

    • Dziś Heartbleed, jutro będzie coś innego. Kodowanie w C wymaga dyscypliny, a tam gdzie jej nie było, są bugi.

  12. Artykuł dno. Typowa zapchaj-dziura. Masa banałów i truizmów. ZERO nowych informacji.
    Ręka w górę ten, który dowiedział się czegoś nowego w temacie pisania bezpiecznego kodu i testowania bezpieczeństwa aplikacji.

    • No dobrze @nicto, ale wyraź proszę, czego oczekujesz i czego chciałbyś się dowiedzieć, bo jak rozumiem cel publikowania tego typu tekstów jest taki, że mają one wywoływać wartościową dyskusję.

  13. Napisałem wyraźnie. Oczekuję nowych informacji, które w jakimkolwiek stopniu będą dla mnie przydatne. Weźmy na przykład artykuł o Heartbleed. Dzięki niemu zacząłem przyglądać się procesowi uaktualniania systemów z których korzystam. Wiem teraz, że Ubuntu i Debian ma załatanego OpenSSLa. Artykuły opisujące słabości kart z Paypassem spowodowały, że jestem świadomy zagrożeń z nimi związanych. I tak dalej, i tak dalej.
    A teraz weźmy twój artykuł. Czego można się z niego dowiedzieć? Że im bardziej skomplikowany/dłuższy kod tym trudniej go sprawdzić? I że nie ma systemów w 100% bezpiecznych. Naprawdę uważasz te truizmy za cokolwiek warte? No i gdzie twoim zdaniem jest ta “wartościowa” dyskusja?
    A tak z innej beczki, rozśmieszyło mnie to zdanie:
    “Zacznijmy jednak od refleksji natury ogólnej, by potem przejść do finalnych konkluzji.”
    To mogłoby być zadanie na jakiś konkurs, na przykład pod tytułem “Napisz to po polsku”.

    I jeszcze sugestia, w jednym z ostatnich artykułów o Heartbleed jest odnośnik do materiału, w którym autor, nie wprost, twierdzi, że to język C jest odpowiedzialny za tę porażającą ilość błędów, które pojawiają się w oprogramowaniu. I to jest temat na ciekawy artykuł dla specjalisty z dziedziny bezpieczeństwa.

    Pozdrawiam i życzę ciekawszych tekstów.

    • Otóż @nicto, wartościowej dyskusji wszyscy goście Niebezpiecznika mogą oczekiwać również od Ciebie i choć Twój komentarz ocieka jadem, to bardzo Ci dziękuję za Twoją opinię. Szanuję ją. Mam nadzieję, że kiedyś trafię którymś ze swoich tekstów także w Twoje potrzeby. O bezpieczeństwie kodu na przykład moglibyśmy długo i treściwie dyskutować, bo tak się składa, że trochę czasu temu w swoim życiu poświęciłem. Zatem, wyluzuj proszę i zapraszam Cię do dyskusji, bo jako specjalista, na pewno masz mnóstwo fajnych rzeczy do powiedzenia czy napisania :-).

    • @nicto
      twój komentarz jest podobny do tego:
      “wchodzę do sklepu, a tam są pomiędzy wartościowymi dla mnie artykułami, również rzeczy, które mnie w ogóle nie interesują, skandal!”.
      Ty byś chciał żeby w sklepie były TYLKO rzeczy dla CIEBIE, proponuję:
      1. skup się tylko na rzeczach Ciebie interesujących, albo
      2. zmień sklep, albo
      3. utwórz własny sklep z rzeczami tylko dla siebie.

    • podobnie jak kol. *nicto* poczułem pewien niedosyt po lekturze tego artykułu, spodziewałem się nieco pogłębionej analizy tego konkretnego błędu, oceny, czy to dzieło przypadku (co z artykułu z grubsza wynikało), czy może chodziło o jakiś szczwany spisek.

      Tym bardziej, że zanim ta afera się objawiła tak bardzo efektownie, byłocały szereg niepokojących incydentów związanych z wirtualnymi serwerami i nie było wcale jasne jak zdobywano w nich uprawnienia root, co jednak niepokoiło wielu i – przypuszczam – mogło sie też przyczynić do wykrycia luki w OpenSSL (to moje przypuszczenie).

      W popularnym artykule na tak medialny temat mozna by tego oczekiwać.

      Ale oczywiście nie mam aż takich pretensji do tekstu jak obcesowy nieco *nicto*.

    • @JG: Moim założeniem było napisanie krótkiego tekstu i wyrażenie w nim poglądu, że wymuszane przez pośpiech kompromisy na jakości kodu, skracanie pod wpływem nacisku rynku czasu trwania czy ograniczanie zakresu testów, brak procesów weryfikacji spełnienia wymagań dotyczących bezpiecznego tworzenia kodu źródłowego, ale też kiepska jakość specyfikacji wymagań bezpieczeństwa (żeby nie było, że tylko programiści są źli) sprawiają, że „security bugs” są liczniejsze niż nam się na pierwszy rzut oka wydaje i że większość z nich kiedyś da nam się (boleśnie) we znaki. Moją intencją było wywołanie dyskusji, w trakcie której wszyscy uczestnicy mieliby okazję podzielić się swoją wiedzą na ten temat. Sprawy te są niby oczywiste, ale jednocześnie niewiele się w tej dziedzinie zmienia na lepsze, więc chyba warto o tym mówić czy pisać wprost. Oczywiście, można pokusić się o pogłębioną analizę, ale to już jest temat na obszerniejszy artykuł.

  14. Wyśmienity artykuł Panie Januszu. Krótko, zwięźle i na temat. Haters gonna hate.

  15. Rynek pokazał jak bardzo tak naprawdę wszystkich obchodzi bezpieczeństwo – załatano serwisy, ale tak naprawdę nikt (nawet banki!) nie kazały zmieniać haseł swoim użytkownikom, a sami użytkownicy tych haseł też nie zmienili. Prawda jest taka, że wszyscy mają bezpieczeństwo w nosie (zarówno hasła jak i zabezpiezcenia komputerów i danych). Mógłbym krzyknąć “kto robi kopie zapasowe ręka w górę”, ale tutaj mamy grupę ludzi razczej wyjątkowo traktujących swoje komputery.

  16. Pracowalem przez lata z wieloma ekipami i powiem jedno … bledow nie da sie uniknac przez niechlujstwo programistow … prosty przyklad – wszedzie tam gdzie wpisuje sie jakies dane w ramach testow nie ma imion tylko dupa … dupa itd … wlasnie niechlujnosc programistow to najwiekszy problem no i rzecz jasna kazdy z nicgu uwazza ze jego kod to perfekcja … dobry kod wyrabia sie tysiacami linijek, wielokrotnymi powrotami do projektu po czasie i trymaniem sie zasad a z tym szczegolnie mlodzi gniewni maja mega problemy

    • sorki za bledy … pozno jest :)

  17. Tak właśnie odebrałem ten artykuł – jako impuls do dyskusji. Oczywiście, że profesjonalista może odebrać to jaki zbiór pewnych oczywistych kwestii, ale już dla osób, które specjalistami nie są, artykuł może pomóc zrozumieć o co w tym wszystkim chodzi. Taka bardziej mainstreamowa strona niebezpiecznika. ;-)

    Jednocześnie w pełni zgadzam się z komentarzem @kravietz – korporacje są w stanie udzielić odpowiedniego wsparcia, chociażby finansów, za które można wykonać testy (tu chyba nawet statyczna analiza kodu wykazałaby możliwy underrun). Niestety oszczędzając na czym tylko się da, nie wspierają softu, od którego są uzależnieni. Szkoda.

    A co do samego bugu – to pokazuje, że trzeba od młodości wykształcać w programistach nawyk dodawania odpowiednich walidacji przy zarządzaniu pamięcią (i karać za nieposłuszeństwo ;-)). Zawsze i wszędzie.
    Szczerze mówiąc podobnie jak @He zdziwił mnie brak jakichkolwiek zabezpieczeń w tak wrażliwym miejscu, przecież dopuszczamy użytkownika do pamięci…

  18. Jednym ze źródeł problemów z kodem jest oczywiście brak staranności ze strony programistów lub problem z wyegzekwowaniem standardów bezpiecznego kodowania. Nie wspomnę już o ekstremalnym przypadku braku standardów bezpiecznego kodowania, bo to też bywa problemem w niektórych firmach.

    Problemem bywa także brak wiedzy o bezpieczeństwie kodu po stronie niektórych developerów.

    Kod powinien przed kompilacją być przeglądnięty przez niezależnego weryfikatora, bo jak Michał w jednym z poprzednich postów zauważył, bywa, że autor widzi w kodzie to, co chce widzieć, zamiast tego, co powinien zobaczyć – bywa, że nie widzi błędów.

    Długo można by pisać na temat błędów kodowania, ale dyskusję trzeba by jakoś ukierunkować, bo każdy język programowania ma specyficzne dla siebie pułapki, w które można łatwo wpaść. Język C dla przykładu daje mnóstwo swobody w pisaniu kodu, ale czasem ta swoboda w połączeniu z brakiem dyscypliny prowadzi do katastrofy, jak pokazała historia z Heartbleed czy wcześniejsze problemy z walidacją certyfikatów.

    Oto przykłady:

    (1) Brak sprawdzania wartości wskaźnika do obszarów pamięci zaalokowanych przy pomocy funkcji malloc() czy calloc(). Wartość NULL powinna dla programisty stanowić istotny sygnał, że alokacja pamięci się nie powidła i – co się z tym wiąże – żeby nie wykonywać w dalszej kolejności żadnej arytmetyki na wskaźnikach, bo tym sposobem, program może wkroczyć na „obcy grunt”, a stąd już tylko krok do wycieku pamięci lub załamania wykonywania programu. Prosta instrukcja warunkowa może zdecydować o braku podatności w kodzie.

    (2) Użycie funkcji realloc() bez wcześniejszego wyczyszczenia pierwotnego bufora pamięci, jeśli ma być on użyty do przetwarzania innych (przykładowo mniej wrażliwych) danych, niż dane dotąd w nim zapisane.

    (3) Próba zwalniania dynamicznie przydzielonej pamięci dla tablicy obiektów jedną instrukcją, zamiast iteracyjnie – pętlą po poszczególnych elementach tablicy.

    (4) Brak sprawdzania (walidacji) danych wejściowych, pozyskiwanych przez procedury programu z niezaufanych źródeł, zwłaszcza ze STDIN, ale też z interfejsów do innych systemów.

    (5) Brak sprawdzania maksymalnych wartości danych możliwych do przechowania w zmiennych określonego typu (uwaga na zmienne signed/unsigned).

    (6) Brak ‘scramblingu’ dynamicznie zaalokowanych obszarów pamięci funkcjami malloc() lub calloc(), w których były przechowywane wrażliwe dane (na przykład hasła) przed ich zwolnieniem przy pomocy funkcji free(). Nie liczyłbym na to, że funkcja free() zrobi to bezpiecznie za nas.

    (7) Brak jawnego przypisania wartości NULL do wskaźników do pamięci zwolnionej wcześniej przy pomocy funkcji free().

    Jeszcze inny problem pojawia się przy ‘mixie’ kodu w C i C++. Programiści często próbują zwalniać pamięć zaalokowaną przy pomocy funkcji malloc() czy calloc() funkcją delete() zamiast free(). Bywa też, że próbują zwalniać przy pomocy funkcji free() pamięć dynamicznie przydzieloną przy pomocy funkcji new(), co też jest błędem.

    Ciekawe jest to, że błędy przeważnie polegają na braku elementarnych weryfikacji w kodzie :-(

  19. “Ktoś kiedyś powiedział…”, “Z publikowanych w Internecie statystyk wynika, że…” – przydałyby się jakieś źródła, albo takie sformułowanie które jasno da do zrozumienia, że jest to tylko i wyłącznie opinia autora.

  20. Idealnym rozwiązaniem systemowym jest standaryzacja security w SDLC, ale to jest temat na zupełnie oddzielny artykuł.

  21. Czytam, czytam – i tak sobie myślę. Problem jest – problem znany mi dobrze. Programista jest trybikiem w maszynie. Presja zabija poprawność i tworzenie w sposób przemyślany. Mam na tapecie pewien moduł, który pewnym rozporządzeniem ma zmienić swoją funkcjonalność w sposób diametralny. Nowe wymagania, dochodzi obsługa nomen-omen PKI, zmiana zakresu przetwarzanych danych, zmiana wyjść. Wejście też nieco się zmienia. Oczywiście wszystko można – można napisać ten moduł w super sposób, nawet się chce. Problem w tym, że 1 maja on ma działać produkcyjnie u klientów, bo od tego zależy czy zechcą dalej płacić. Co zatem ma zrobić development? Iść do kierownictwa i powiedzieć – zrobimy, za dwa miesiące dobrze, porządnie i będzie caca na lata (lub do nowej zmiany przepisów). Odpowiedź jest prosta i szybka – beta ma być przed świętami (zostają 3 dni), testy po świętach w trakcie wdrażania na produkcji, jak się coś wyp… to łatajcie co się da, bo musi być i koniec “Jak się wam uda to partia was popierze, jak nie – to partia was rozliczy.”. I jak ma powstać dobry moduł? Na wejściu następuje rezygnacja z testów na debilo-odporność – bo chodzi o to, żeby zadziałało i robiło to co jest w zarządzeniu. Rezygnacja ze sprawdzeń poprawności danych – bo w tym czasie trzeba dorobić wyplucie danych do PDF, bazę danych pod to tworzy się na kolanie – w trakcie tworzenia funkcji dodaje się pola jak czegoś braknie. Potem u klienta ujednolicony SQL zapuszczony – byle tylko nie pomylić wersji n-tej skryptu. Święta – sprawdzanie co się da sprawdzić, poprawki. Szykowanie wersji N+1 Last Rc poprawione 2, a za tydzień paczka do repozytorium, kretyński mail do klientów: “przygotowaliśmy nowe funkcjonalności ble ble ble”, sztab z debugerem w ręce pod telefonem i patrzymy. I szanowni koledzy się zapytam – gdzie jest to o czym piszecie – poprawność standardów, zgodność, testy, weryfikacje, doskonalenie kodu? Nie ma na to szans, bo cel biznesowy stoi wyżej celu jakościowego. A potem jakoś to będzie. I na deser pytanie kiedy wyszło rozporządzenie? Dawno. Tyle że wszyscy są zajęci łataniem i nikt nie śledzi zmian w przepisach…

    • Jak obserwuję niezawodność oprogramowania w Smart TV (bo ostatnio ten temat mnie interesował), to chyba ono terz jest tworzone w tym trybie jak kolega wyżej opisał :) albo .. developerzy uczą się.

  22. No nieeeee, do czego ja jestem zdolny, przepraszam!
    terz = też!!!!
    To właśnie ten niesamowity pośpiech :) bo już muszę zamykać komputer!

  23. Afera heartbleed’a robi się głośna, a w NSA siedzą i śpiewają…

    I can hear your heartbleed,
    I can hear your heartbleed.

  24. Każdy człowiek na ziemi popełnia błędy – a programista to też człowiek :) uważam, że doświadczenie w pracy oraz wykształcona i ‘ wyluzowana ‘ kadra dają jednak wiele. Sprawdziłem to na własnej skórze. Pół roku temu zmieniłem miejsce pracy na firmę SMT SOFTWARE i dzięki miłej atmosferze, moja praca jest bardziej wydajna dzięki zmniejszonemu poziomowi stresu. Skupiam się na tym co powinienem. Wszystkim szukającym pracy gorąco polecam SMT WARSZAWA!

  25. […] O błędach programistów i testowaniu oprogramowania w kontekście Heartbleed […]

Odpowiadasz na komentarz Marek

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: