No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).
Źródło: http://heartbleed.com/
Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.
Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.
Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.
Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.
Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).
Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.
UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:
lsof -n | grep ssl | grep DEL
