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
No nieźle. W moim przypadku (Debian Sqeeze) okazuje się, że zadziałało moje własne security by laziness ;o), skoro ta wersja nie jest podatna – czyli czasem opłaca się zostać na starszej wersji. Myślałem o przesiadce na stable, ale po pierwsze pojawia się kłopot z Intel microcode (a dla mojego Atoma D525 to istotne), wycięto też zdaje się Suhosin (tego posunięcia akurat nie rozumiem). Dalej się nie zagłębiałem bo brak czasu i chęci, zmienię system pewnie po wymianie sprzętu, ale jak raz ten aktualny się nie chce popsuć, a poza tym cierpię ostatnio na chroniczny brak zaskórniaków na swoje zabawki ;o)
Tak czy siak dzięki za info, nie śledzę na bieżąco newsów. W Sqeeze (mimo braku podatności) 6 kwietnia wymieniono pakiety openssh-client, openssh-server i ssh.
Ta, security by oldstability. 😉
Co do microcode, to opisałem aktualizację microcode we Wheezy – HTH. Suhosin IMHO nie jest tak krytyczny, ale faktycznie, nie ma go we Wheezy (w unstable już jest). Tak czy inaczej niebawem kończy się wsparcie bezpieczeństwa dla Squeeze’ego, więc jednak pomyśl o aktualizacji.
W tamtym tekście napisałeś, że „chyba nie działa, śladu w dmesg żadnego” więc dla mnie to żaden wiążący „poradnik” ;o) Poza tym nie robiłem jeszcze dist-upgrade, więc nie wiem co jeszcze z listy niespodzianek (poza mikrokodem i suhosinem) mnie wówczas czeka.
Tekst „chyba nie działa” dotyczył wyłącznie ładowania mikrokodu online. Z rebootem nie bardzo ma co nie zadziałać. 😉