Security jest walką, więc zmieniaj klucze dla szatana!

O fatalnej pomyłce w Debianowym openssl pisano już wszędzie, np. w LWN oraz na wiki samego Debiana. Nie będę więc powtarzał szczegółów. W skrócie, jeden z deweloperów zakomentował linijkę, która w pewnych sytuacjach mogła korzystać z niezainicjowanej pamięci. Korzystanie z pamięci o nieznanej zawartości jest zazwyczaj błędem programistycznym, w tym przypadku jednak celem było zasianie (ang. seed) generatora liczb pseudolosowych.

Generator jest implementacją algorytmu, który na podstawie jakiś danych, czyli własnie seeda, daje różne liczby losowe. Po zmianie wprowadzonej przez Debianowca jedynym źródłem początkowej losowości był wynik funkcji getpid(), zwracającej identyfikator procesu. W typowym systemie linuksowym ograniczało to możliwą liczbę pierwotnych danych — a co za tym idzie, liczbę możliwych wygenerowanych liczb pseudolosowych — do około 32 tysięcy. Zaledwie! Tak mała liczba kombinacji umożliwia odtworzenie w kilka godzin wszystkich możliwych kluczy kryptograficznych wygenerowanych tak zasianym generatorem.

obrazek z xkcd, wykonanie desp, pomysł ja.

Użycie jako początkowego ziarna zawartości niezainicjowanej pamięci jest rozwiązaniem sprytnym. Przynajmniej na pierwszy rzut oka. Gdzieś w głębi zaczęły się jednak pojawiać wątpliwości.

Pytanie pierwsze: jak to możliwe, że zawartość niezaincjalizowanej pamięci miała tak duży wpływ na działanie generatora PRNG? Wpływ kluczowy, bo usunięcie jej spowodowało gigantyczną porażkę.

Pytanie drugie: czy inne dystrybucje są podatne w podobny sposób?

Zaczynając od pytanie drugiego. Korzystanie z niezaincjalizowanej pamięci jako źródła losowych danych jest złym pomysłem. Nie ma żadnej gwarancji, że znajdujące się tam dane są nieprzewidywalne. Linuksowy glibc realizuje przydział pamięci na dwa sposoby. Dla małych obszarów używany jest sbrk(), większe (powyżej 128KiB z dokładnością do autotuningu) zdobywane są przez mmap(). W wyniku mmap() zwracany jest obszar wyzerowany przez jądro. Czyli całkowicie przewidywalny, w 100% wypełniony wartością 0. O losowości nie ma co marzyć, sytuacja jest analogiczna do złej łaty w Debianie, a sytuacja dotyczy wszystkich dystrybucji!

To jednak dotyczy tylko dużych alokacji, bufor w openssl może być dużo mniejszy, mniejszy od progu zerowania przeze jądro. Tu należy sobie zadać pytanie: co jest w niezainicjowanej pamięci? Dane, które były tam wcześniej, wpisane kiedy jeszcze pamięć ta należała do innego programu. Łatwo sobie wyobrazić, że różnego rodzaju łatki typu hardening, czyli ,,zwiększające bezpieczeństwo” zerują każdą pamięć przekazywaną programom. W celu uniknięcia wycieku informacji z wcześniej działajacych programów. Tak więc nawet mały, niezainicjowany obszar pamięci może być wyzerowany i jako taki zupełnie nie nadawać się do inicjowania pracy generatora pseudolosowego.

Zerować obszar miała też pierwotna wersja debianowej łaty:

+ /* Keep valgrind happy */
+ memset(tmpbuf, 0, sizeof tmpbuf);

Została zastąpiona wykomentowanie generującej ostrzeżeni linijki.

Cóż więc z podatnością? Czy openssl zawsze działa na przewidywalnych, zerowych danych i jako takie stanowi zagrożenie na wszystkich linuksach? Odpowiadam: nie, a twierdzenie zawarte w początkowych akapitach tej jest nie do końca prawdziwe.

Poza numerem procesu, niezainicjowana pamięć nie jest jedynym źródłem entropii dla openssl. Więc nawet jeśli jest zerowa, PRNG jest zasiewany innymi losowymi bitami. Przynajmniej w oryginalnym kodzie. Deweloper Debiana usunął zasiewanie niezależnie od sposobu. Z powodu tego, że jedna z metod pozyskiwania entropii powodowała ostrzeżenia, debianowiec zablokował wszystkie. Klasyczny przykład wylania dziecka z kąpielą.

Powstające wątpliwości zostały ugaszone, a openssl na Linuksie jest w porządku. Mój błąd polegał na uznaniu niezaincjowanej pamięci za jedynego źródła entropii, gdy tymczasem jest ono jednym z kilku.

---

Archived comments:

amag 2008-05-16 18:15:46

Fajny opis. Przyznam, że sam się zastanawiałem w jednym z komentarzy czy nie istnieją łaty na jądro zerujące porzucane/inicjowane obszary pamięci. Nie wiedziałem nic o tym, że oryginalnie była to tylko jedna z metod.

Za ten tytuł powinieneś dostać jakieś piwo- świetne!

Zal 2008-05-16 19:13:11

Nie tylko interesujące, ale i przekomiczne ;D Świetny demotywator :]

zdz 2008-05-16 22:23:15

Wiesz Zal, cholernie nam z kumplem przykro z powodu tych motywatorów. Nigdzie się nie podpisaliśmy, nawet w EXIFie, a obrazki zaczynają krążyć --> http://metasploit.com/users/hdm/tools/debian-openssl/

#!/bin/nwkr devblog 2008-06-17 00:19:10

Bezpieczeństwo SSH to walka, więc ulepsz sshd_config dla szatana!

Bardzo wiele serwerów korzysta z protokołu SSH do udostępniania powłoki. Wszyscy wiedzą, że jest to protokół bardzo bezpieczny. Mniej osób zdaje sobie sprawę z tego, że najsłabszym ogniwem w systemie zabezpieczeń systemów jest użytkow[...]

eversesseaste 2012-11-15 12:32:56

<a href=http://buyviagraonlineds.com/#16060>generic viagra</a> - <a href=http://buyviagraonlineds.com/#19824>buy viagra online</a> , http://buyviagraonlineds.com/#8263 buy viagra

insepterilelo 2012-11-16 21:43:15

<a href=http://buyviagraonlineds.com/#14365>buy generic viagra</a> - <a href=http://buyviagraonlineds.com/#8341>buy viagra</a> , http://buyviagraonlineds.com/#20339 generic viagra