Wokół błędu w generowaniu liczb pseudolosowych w pakiecie OpenSSL z dystrybucji Debian GNU/Linux wywiązała się żywa dyskusja. Programista projektu OpenSSL i współtwórca Apache Foundation, Ben Laurie, najpierw nakreślił swoje stanowisko we wpisie w blogu zatytułowanym Vendors Are Bad For Security. Jego zdaniem opiekunowie pakietów nie powinni modyfikować kodu źródłowego, na którym się nie znają. Zamiast tego powinni zawsze zwracać się do programistów, którzy są w stanie odpowiednio ocenić i ewentualnie dołączyć poprawki do danego modułu czy bloku instrukcji. Gdyby usuwanie błędów odbywało się na tej drodze, nie doszłoby do opisywanego problemu.

Jednak w tym przypadku odpowiedzialności nie należy szukać tylko wśród opiekunów debianowego pakietu OpenSSL. Z pewnością zdawali oni sobie sprawę z faktu, iż modyfikacje mogą przyczynić się do generowania gorszych liczb pseudolosowych – dlatego też umieścili odpowiednie potwierdzenie na liście dyskusyjnej deweloperów OpenSSL, zanim wprowadzili fatalną poprawkę do pakietu. Również po tym fakcie nie wnoszono żadnego sprzeciwu. W innym wpisie w blogu Laurie poruszył między innymi temat problemów komunikacyjnych między członkami zespołu pracującego nad biblioteką OpenSSL.

Powszechnym zwyczajem jest, że producenci poszczególnych dystrybucji GNU/Linuksa zmieniają kod źródłowy kernela czy aplikacji, aby wprowadzić łatki i aktualizacje bezpieczeństwa do swoich pakietów. Szczególnie w przypadku mniejszych projektów programistycznych może trochę potrwać, zanim odpowiednie zmiany i poprawki zostaną zasymilowane przez oryginalny projekt i trafią do jego repozytorium. Ponieważ ze względu na kwestie stabilności producenci z reguły nie korzystają z najnowszych wersji modułów, muszą najczęściej dostosowywać poprawki do starszych wersji. W rozmowie z heise Security istnienie tego problemu potwierdzili także Martin Schulze i Florian Weimer z projektu Debian GNU/Linux. Wskazali oni jednak na fakt, że opiekunowie pakietów Debiana powinni zgodnie z wytycznymi programistycznymi możliwie ściśle współpracować z deweloperami modułów, tak aby ewentualne zmiany trafiały również do oryginalnych źródeł.

Bezpośrednią przyczyną zmian w pakiecie OpenSSL były komunikaty o błędach pochodzące z narzędzia kontroli jakości Valgrind; program ten zgłaszał potencjalne wycieki pamięci w sekcji szyfrującej. Zmiana wykonana przez opiekunów pakietu Debiana miała na celu wyłączyć możliwość niestandardowych dostępów do wolnych obszarów pamięci, które z reguły oznaczają błędy programistyczne. Jednak zamiast uniemożliwić poprawne wywołania funkcji na wolnych obszarach pamięci, rzeczona poprawka odebrała funkcji ssleay_rand_add() możliwość pobierania danych z zewnętrznych źródeł (tzw. entropy pool). Nieużywany obszar pamięci jest jednak tylko jednym z wielu możliwych źródeł wykorzystywanych do generowania liczb pseudolosowych.

Konsekwencją tego stanu rzeczy był fakt, że debianowa biblioteka OpenSSL do generowania liczb pseudolosowych mogła wykorzystywać jedynie 16-bitowe identyfikatory procesów systemowych. To z kolei spowodowało, że wygenerowane klucze SSH i SSL/TLS były bardzo łatwe do przewidzenia, a tym samym do złamania za pomocą prostych ataków typu brute force. Dostępne są już testowe narzędzia i exploity (w tym również zawarte we frameworku Metasploit) potrafiące złamać słabe klucze SSH o długości do 4096 bitów. Bazują one na listach tworzonych przez obliczanie kluczy dla wszystkich 65536 możliwych identyfikatorów procesów. Programy odgadujące klucze SSH działają tylko wówczas, jeśli na serwerze z dostępem przez SSH użytkownik samodzielnie wygenerował i zainstalował słaby klucz służący do autentykacji nie wymagającej podawania hasła.

W przypadku certyfikatów X.509 dla SSL i TLS sytuacja nie jest jeszcze jasna. Na debianowych stronach Wiki przedstawiono wprawdzie metodę konwertowania kluczy X.509 w formacie PEM do SSH, jednak autorzy opisu zaznaczyli, że programy testujące SSH nie znajdują słabych kluczy, jeśli certyfikaty zostały wygenerowane za pomocą niezabezpieczonych i podatnych na ataki wersji biblioteki OpenSSL. W razie jakichkolwiek wątpliwości użytkownicy powinni wygenerować na nowo wszystkie klucze SSH i SSL stworzone od września 2006 oraz wycofać stworzone na ich podstawie certyfikaty. W szczególności wiele pracy czeka w tym względzie wystawców certyfikatów.

Zobacz także

• Słabe klucze kryptograficzne w Debianie, Ubuntu i innych, heise Security

• Vendors Are Bad For Security, wpis w blogu Bena Laurie'ego

• Strony wiki Debiana z informacjami na temat błędu w OpenSSL

(pwi)