Usunięcie dwóch linii „podejrzanego” kodu osłabiło klucze Debiana na prawie dwa lata
W 2008 roku Debian ogłosił, że jego pakiet OpenSSL generował przewidywalny materiał losowy. Przyczyną była specyficzna dla Debiana zmiana wprowadzona w 2006 roku: wyłączono fragment kodu związany z dostarczaniem danych do generatora losowego, ponieważ narzędzia do analizy pamięci zgłaszały ostrzeżenia dotyczące używania niezainicjalizowanych danych. Skutek był dramatyczny: przestrzeń możliwych kluczy generowanych przez dotknięte wersje została mocno ograniczona, więc klucze mogły być odgadywane. Debian zalecił wygenerowanie na nowo całego materiału kryptograficznego utworzonego przez podatne wersje. To podręcznikowa historia o poprawce wyglądającej rozsądnie lokalnie, która naruszyła niewidoczne założenie bezpieczeństwa.
Problem nie tkwił w RSA ani DSA
Debian w swoim komunikacie bezpieczeństwa opisał podatność CVE-2008-0166 jako przewidywalny generator liczb losowych w debianowym OpenSSL. Algorytmy kryptograficzne wykorzystywane do kluczy nie zostały nagle złamane matematycznie. Zawiódł etap generowania sekretów. Jeśli „losowy” klucz pochodzi z bardzo małego i przewidywalnego zbioru możliwości, siła późniejszego szyfrowania niewiele pomaga: napastnik może po prostu sprawdzić kandydatów na klucz.
Zmiana miała usunąć problem wykrywany przez narzędzia
Historia stała się słynna, ponieważ feralna modyfikacja była próbą poradzenia sobie z ostrzeżeniami narzędzia Valgrind dotyczącymi odczytów niezainicjalizowanej pamięci. W kodzie kryptograficznym takie dane były używane jako jeden ze składników zasilających pulę entropii. Wycięcie fragmentu uspokoiło analizator, ale jednocześnie znacząco ograniczyło różnorodność stanu generatora. To nie znaczy, że używanie niezainicjalizowanej pamięci jest ogólnie dobrym źródłem losowości. Lekcja dotyczy tego, że modyfikacja kodu kryptograficznego wymaga zrozumienia roli każdego przepływu danych w całym mechanizmie.
Słabe klucze rozlały się poza same maszyny Debianowe
Advisory Debiana zaznaczało, że inne systemy mogły być pośrednio dotknięte, jeśli importowały klucze wygenerowane na podatnym Debianie. Sekret może zostać wygenerowany na jednej maszynie, a potem latami używany gdzie indziej. Dlatego naprawienie pakietu nie wystarczało. Trzeba było zidentyfikować i wymienić klucze SSH, certyfikaty i inny materiał kryptograficzny utworzony podczas okresu podatności.
DSA ucierpiało szczególnie mocno
Debian zwrócił uwagę, że wszystkie klucze DSA używane na dotkniętych systemach do podpisywania lub uwierzytelniania należy traktować jako skompromitowane. DSA wymaga tajnej wartości losowej podczas tworzenia każdego podpisu. Jeżeli ta wartość jest przewidywalna lub źle generowana, może zagrozić kluczowi prywatnemu. To pokazuje, że losowość nie jest potrzebna jedynie podczas tworzenia klucza; niektóre schematy potrzebują jej poprawnie także w kolejnych operacjach.
Największa lekcja: entropia jest częścią powierzchni bezpieczeństwa
Generator losowy może wyglądać jak infrastrukturalny detal pod spodem właściwych algorytmów. W kryptografii jest jednak jednym z fundamentów. Klucz 2048-bitowy nie zapewnia 2048 bitów nieprzewidywalności, jeśli generator potrafi wyprodukować tylko niewielką liczbę możliwych kandydatów. Historia Debiana dobrze pokazuje, dlaczego recenzja zmian w kodzie bezpieczeństwa musi obejmować nie tylko lokalną poprawność i brak ostrzeżeń, lecz także własności systemowe, których zwykłe testy funkcjonalne mogą w ogóle nie zauważyć.
Źródłowy ślad błędu prowadzi do bardzo zwyczajnej dyskusji o Valgrindzie
Archiwalny raport Debiana #363516 pozwala zobaczyć genezę problemu bez późniejszej legendy. Zgłoszenie z 2006 roku dotyczyło tego, że niezainicjalizowane dane używane przez kod RNG powodowały liczne ostrzeżenia Valgrinda. W dyskusji pojawił się pomysł wyłączenia fragmentów, które dodawały takie dane do puli. Późniejsze DSA-1571 stwierdziło, że Debianowa modyfikacja spowodowała przewidywalność generatora OpenSSL i że klucze utworzone z dotkniętych wersji należało odtworzyć. To niezwykle pouczający łańcuch: intencją była poprawa zachowania narzędzia diagnostycznego, zmiana wyglądała lokalnie i rozsądnie, a jej skutkiem było usunięcie kluczowego źródła zmienności z komponentu bezpieczeństwa. Review kryptografii musi więc obejmować także pozornie „porządkowe” patche.
Ograniczona losowość pozwoliła przygotować listy słabych kluczy
Gdy przestrzeń możliwych kluczy generowanych przez wadliwy RNG drastycznie się zmniejsza, problem przestaje przypominać szukanie igły w astronomicznym stogu siana. Debian po ujawnieniu luki dostarczał narzędzia i blacklisty pomagające wykrywać część podatnych kluczy, a administratorzy musieli je unieważniać i generować ponownie. Samo zaktualizowanie biblioteki nie naprawiało bowiem sekretów utworzonych wcześniej: klucz zachowuje swoją słabość niezależnie od tego, jak bezpieczny generator działa dziś. To ważna właściwość incydentów kryptograficznych. Patch zatrzymuje produkcję nowych wadliwych artefaktów, ale certyfikaty, klucze SSH i inne sekrety wygenerowane w okresie błędu mogą wymagać osobnego wyszukania, wymiany i odwołania z systemów, które im ufały.