Jak załatać błąd Heartbleed (CVE-2014-0160) w OpenSSL?

152

Na dzień dzisiejszy znaleziono błąd w OpenSSL, który wpływa na wersje 1.0.1poprzez 1.0.1f(włącznie) i 1.0.2-beta.

Od wersji Ubuntu 12.04 wszyscy jesteśmy podatni na ten błąd. Aby usunąć tę lukę, dotknięci użytkownicy powinni zaktualizować do OpenSSL 1.0.1g.

Jak każdy użytkownik, którego dotyczy problem, może teraz zastosować tę aktualizację ?

security openssl Lucio
źródło
Czy masz wersję programu openssl, której dotyczy problem?
Braiam
Mam łataną wersję 1.0.1-4ubuntu5.12 i zrestartowałem usługę Apache, ale testy na filippo.io/Heartbleed na mojej stronie wciąż mówią, że jestem podatny na atak Czy wiesz, dlaczego?
1
@ Mat Nie wiem, co testuje ta strona, ale może wykryje, że używasz starego klucza. Ponieważ klucz mógł wyciec, musisz go zregenerować.
Gilles
1
Naprawdę nie chcesz aktualizować OpenSSL do hurtowych nowych wersji, to niewiarygodny ból. O wiele łatwiej jest po prostu zainstalować zaktualizowany pakiet, który usuwa
sarnold
czy uruchomiłeś ponownie swoje usługi po aktualizacji?
Axel

Odpowiedzi:

141

Aktualizacje bezpieczeństwa są dostępne dla 12.04, 12.10, 13.10 i 14.04, patrz Informacja o bezpieczeństwie Ubuntu USN-2165-1 .

Najpierw musisz zastosować dostępne aktualizacje zabezpieczeń, na przykład uruchamiając

sudo apt-get update
sudo apt-get upgrade

z linii poleceń.

Nie zapomnij zrestartować usług (HTTP, SMTP itp.), Które korzystają z wersji OpenSSL, której dotyczy problem, w przeciwnym razie nadal będziesz narażony. Zobacz także Heartbleed: co to jest i jakie są opcje jego łagodzenia? na Serverfault.com.

Następujące polecenie pokazuje (po aktualizacji) wszystkie usługi, które należy zrestartować:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Następnie musisz zregenerować wszystkie klucze SSL serwera , a następnie ocenić, czy twoje klucze mogły wyciec, w takim przypadku osoby atakujące mogły odzyskać poufne informacje z serwerów.

Florian Diesch
źródło
23
Nie jestem pewien, czy to działa na Ubuntu 12.04.4 LTS. Po pełnej aktualizacji openssl versiondaje OpenSSL 1.0.1 14 Mar 2012. To nie jest łatana wersja, prawda? A może źle to interpretuję?
Paul Cantrell,
7
Co zrobić z Ubuntu 13.04? Brak dostępnego uaktualnionego openssl :-(
Frodik
20
W Ubuntu 12.04 nawet stała wersja wyświetlaczy OpenSSL 1.0.1 14 Mar 2012. Przeczytaj odpowiedź crimi, aby dowiedzieć się, czy Twoja instalacja zawiera poprawkę.
dan
7
Dzięki, @dan! Ponowne podsumowanie odpowiedzi @ crimi tutaj: jeśli uciekniesz dpkg -l | grep ' openssl 'i dostaniesz, 1.0.1-4ubuntu5.12możesz iść.
Paul Cantrell,
20
Patchowanie i restartowanie nie wystarczy. Musisz zregenerować klucze i ocenić, czy klucze zostały wyciekły, a także inne poufne materiały. Zobacz np. Czy Heartbleed oznacza nowe certyfikaty dla każdego serwera SSL?
Gilles
71

Błąd jest znany jako Heartbleed .

Czy jestem wrażliwy?

Zasadniczo masz wpływ, jeśli w pewnym momencie uruchomisz serwer, dla którego wygenerowałeś klucz SSL. Większość użytkowników końcowych nie jest dotknięta (bezpośrednio); przynajmniej Firefox i Chrome nie używają OpenSSL. SSH nie ma wpływu. Nie ma to wpływu na dystrybucję pakietów Ubuntu (opiera się na sygnaturach GPG).

Jesteś narażony na atak, jeśli korzystasz z dowolnego serwera korzystającego z OpenSSL w wersjach 1.0–1.0.1f (z wyjątkiem wersji oczywiście poprawionych od czasu wykrycia błędu). Dotknięte wersje Ubuntu to zaufane przedpremierowe wersje od 11.10 do oneiric do 14.04. Jest to błąd implementacyjny, a nie usterka protokołu, więc dotyczy to tylko programów korzystających z biblioteki OpenSSL. Jeśli masz program połączony ze starą wersją OpenSSL w wersji 0.9.x, nie ma to wpływu. Dotyczy to tylko programów używających biblioteki OpenSSL do implementacji protokołu SSL; nie ma to wpływu na programy wykorzystujące OpenSSL do innych celów.

Jeśli korzystałeś z podatnego na atak serwera z dostępem do Internetu, uważaj go za zagrożony, chyba że w dziennikach nie ma połączenia od czasu ogłoszenia w dniu 2014-04-07. (Zakłada się, że luka ta nie została wykorzystana przed ogłoszeniem.) Jeśli serwer został ujawniony tylko wewnętrznie, to czy konieczna będzie zmiana kluczy, będzie zależeć od innych zastosowanych środków bezpieczeństwa.

Jaki jest wpływ?

Błąd pozwala każdemu klientowi, który może połączyć się z twoim serwerem SSL, odzyskać około 64kB pamięci z serwera. Klient nie musi być w żaden sposób uwierzytelniany. Powtarzając atak, klient może zrzucić różne części pamięci podczas kolejnych prób.

Jednym z kluczowych elementów danych, które osoba atakująca może uzyskać, jest prywatny klucz SSL serwera. Dzięki tym danym atakujący może podszyć się pod Twój serwer.

Jak mogę odzyskać na serwerze?

  1. Przełącz wszystkie serwery, których dotyczy problem, do trybu offline. Tak długo, jak działają, potencjalnie wyciekają krytyczne dane.

  2. Zaktualizuj libssl1.0.0pakiet i upewnij się, że wszystkie serwery, których dotyczy problem, zostaną zrestartowane.
    Możesz sprawdzić, czy procesy, których dotyczy problem, nadal działają z libssl `` grep ''. (usunięty) „/ proc / / maps”

  3. Wygeneruj nowe klucze . Jest to konieczne, ponieważ błąd mógł umożliwić osobie atakującej uzyskanie starego klucza prywatnego. Postępuj zgodnie z tą samą procedurą, którą użyłeś początkowo.

    • Jeśli korzystasz z certyfikatów podpisanych przez urząd certyfikacji, prześlij nowe klucze publiczne do urzędu certyfikacji. Po otrzymaniu nowego certyfikatu zainstaluj go na serwerze.
    • Jeśli korzystasz z certyfikatów z podpisem własnym, zainstaluj je na swoim serwerze.
    • Tak czy inaczej, przenieś stare klucze i certyfikaty na bok (ale nie usuwaj ich, po prostu upewnij się, że nie są już używane).

  4. Teraz, gdy masz nowe bezkompromisowe klucze, możesz przywrócić serwer do trybu online .

  5. Odwołaj stare certyfikaty.

  6. Ocena szkód : wszelkie dane, które były w pamięci procesu obsługującego połączenia SSL, mogły zostać wyciekły. Może to obejmować hasła użytkownika i inne poufne dane. Musisz ocenić, jakie mogły być te dane.

    • Jeśli korzystasz z usługi, która umożliwia uwierzytelnianie haseł, hasła użytkowników, którzy nawiązali połączenie od czasu przed ogłoszeniem luki w zabezpieczeniach, należy uznać za zagrożone. (Nieco wcześniej, ponieważ hasło mogło być przez jakiś czas nieużywane w pamięci.) Sprawdź swoje dzienniki i zmień hasła każdego użytkownika, którego dotyczy problem.
    • Unieważnij także wszystkie sesyjne pliki cookie, ponieważ mogły zostać naruszone.
    • Certyfikaty klienta nie są zagrożone.
    • Wszelkie dane, które zostały wymienione od czasu, zanim luka w zabezpieczeniach mogła pozostać w pamięci serwera, a więc mogły zostać wyciekły do ​​atakującego.
    • Jeśli ktoś zarejestrował stare połączenie SSL i odzyskał klucze serwera, może teraz odszyfrować transkrypcję. (Chyba że zapewniono PFS - jeśli nie wiesz, nie było.)

Jak mogę odzyskać na kliencie?

Istnieje tylko kilka sytuacji, w których wpływają na aplikacje klienckie. Problem po stronie serwera polega na tym, że każdy może połączyć się z serwerem i wykorzystać błąd. Aby wykorzystać klienta, muszą być spełnione trzy warunki:

  • Program kliencki użył błędnej wersji biblioteki OpenSSL do wdrożenia protokołu SSL.
  • Klient podłączony do złośliwego serwera. (Na przykład, jeśli łączysz się z dostawcą poczty e-mail, nie stanowi to problemu). Musiało to nastąpić po tym, jak właściciel serwera dowiedział się o luce, prawdopodobnie po 2014-04-07.
  • Proces klienta miał poufne dane w pamięci, które nie zostały udostępnione serwerowi. (Więc jeśli właśnie pobiegłeś, wgetaby pobrać plik, nie było danych do wycieku.)

Jeśli zrobiłeś to między 2014-04-07 wieczorem UTC a aktualizacją biblioteki OpenSSL, weź pod uwagę wszelkie dane znajdujące się w pamięci procesu klienta.

Bibliografia

Gilles
źródło
4
Nie wierzę, że „dotyczy to tylko połączeń SSL / TLS po stronie serwera” jest prawdą. openssl.org/news/secadv_20140407.txt mówi, że może ujawnić sekrety klienta lub serwera. ubuntu.com/usn/usn-2165-1 zgadza się. Szanse, że użyjesz certyfikatów klienta podczas łączenia się ze złośliwym serwerem, są niewielkie, ale istnieje taka możliwość.
armb
@armb Masz rację. Nie ma nawet znaczenia, czy używane są certyfikaty klienta, wyciek danych nie jest związany z użyciem certyfikatów. Mam poprosił o pomoc specjalistów .
Gilles
Certyfikaty klienta mają miejsce w przypadku wycieku kluczy prywatnych, ale tak, hasła, uwierzytelniające pliki cookie itp. Mogą przeciekać. Jednak przy typowym użyciu klienta opartego na OpenSSL, takiego jak curl lub wget, nie będziesz mieć tajemnic dla innych witryn w pamięci podczas łączenia się ze złośliwym serwerem, więc w takim przypadku myślę, że jedynym wyciekiem byłoby, gdybyś dał tajne dane klienta w oczekiwaniu na przekazanie ich do legalnej witryny, a Heartbleed ujawnił je podczas uzgadniania, zanim weryfikacja certyfikatu ujawni, że nie masz połączenia z właściwą witryną.
armb
1
@Gilles Być może zainteresują Cię odpowiedzi na pytanie, którzy klienci są podatni na Heartbleed? . Udało mi się zdobyć „interesującą” pamięć na nginx (tryb proxy), wget, linki i inne.
Lekensteyn,
1
@ MuhamedHuseinbašić Pakiet opensslzawiera narzędzia wiersza poleceń. Nie jest używany przez aplikacje korzystające z biblioteki OpenSSL do implementacji protokołu SSL (takie jak Apache). Ale powinieneś po prostu zastosować aktualizacje bezpieczeństwa dystrybucji.
Gilles
40

Aby zobaczyć, która wersja OpenSSL jest zainstalowana w systemie Ubuntu:

dpkg -l | grep openssl

Jeśli wyświetli się następująca wersja, należy dołączyć łatkę do CVE-2014-0160.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Patrząc na https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 , pokazuje, jaki rodzaj błędów został naprawiony:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...
crimi
źródło
2
Uaktualniłem i otrzymałem wersję 5.12, ale to narzędzie wciąż mówi mi, że jestem podatny na atak filippo.io/Heartbleed Thoughts?
toxaq
3
Przetestowałem nasze zaktualizowane serwery po tej stronie i powiedział mi, że nie ma na mnie wpływu. Czy zrestartowałeś system, a przynajmniej jesteś pewien, że wszystkie niezbędne procesy zostały zrestartowane?
crimi
3
Po zaktualizowaniu OPENSSL wystarczyło zrestartować usługę Apache, ale wdzięczność nie pomogła . Musiałem przejść i uruchomić ponownie, używającsudo service apache2 restart
Tom Hert
1
Właśnie znalazłem przyczynę mojej podatności: zainstalowałem mod-spdy-beta. Po usunięciu i ponownym uruchomieniu apache wszystkie testy są teraz zielone.
Andreas Roth,
3
Aktualizacja opensslnie naprawia aplikacji takich jak Apache, Nginx czy postfix. Musisz je zaktualizować libssl1.0.0i uruchomić ponownie, jak wyjaśniono w innych postach.
tnj
17

Jeśli Twoje repozytoria apt-get nie zawierają żadnej wstępnie skompilowanej wersji OpenSSL 1.0.1g , po prostu pobierz źródła z oficjalnej strony i skompiluj je.

Poniżej jednego wiersza poleceń do kompilacji i instalacji ostatniej wersji openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Zamień stary plik binarny openssl na nowy za pomocą dowiązania symbolicznego.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Wszyscy jesteście dobrzy!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Por. Ten post na blogu .

Uwaga: Jak stwierdzono w poście na blogu, to obejście nie naprawi „serwera Nginx i Apache, który musi zostać ponownie skompilowany ze źródłami openSSL 1.0.1g”.

Quentin Rousseau
źródło
2
Jak zwykle Ubuntu nie zapewnia nowej wersji nadrzędnej, ale załatał wersje dla wszystkich obsługiwanych wersji, aby ograniczyć zmiany do minimum.
Florian Diesch
1
Uwaga: Upewnij się, że zrestartowałeś serwer po aktualizacji OpenSSL. Apache i Nginx przejęły nową bibliotekę i luka została zamknięta.
dAngelov
6
Heh, teraz, kiedy poświęcam czas na przeczytanie szczegółów tego wpisu, jestem jeszcze bardziej przerażony - ściąganie tarballa z jakiegoś przypadkowego miejsca poza Internetem, rozpakowywanie i wykonywanie jego części, ponieważ root jest po prostu lekkomyślnym zachowaniem. Byłoby nieco lepiej, gdyby podpisy tarballa zostały pobrane i sprawdzone, ale upewnienie się, że potwierdzasz, że podpisy zostały podpisane odpowiednim kluczem, samo w sobie jest trudnym pytaniem. Dystrybucje podjęły już starania, aby zapewnić bezpieczne pochodzenie tarballi i łatek. Dzięki.
Sarnold
2
Może to być dobry pomysł, aby skompilować ze źródeł NOW i zainstaluj nowszą jeden później z apt, że Twój sposób bardziej bezpieczny niż bez expectly na starszych wersjach Ubuntu byle tylko moje dwa centy
nwgat
2
@sarnold openssl.org nie wydaje się przypadkowym miejscem do pobrania źródła dla openssl. Kanoniczny powinien sprawić, że stanie się to niepotrzebne, ale openssl.org powinien być autorytatywnym podmiotem działającym na rynku.
Rustavore,
12

Dla tych, którzy nie chcą robić aktualizacji pakietu na cały serwer. Przeczytałem dzisiaj kilka z tych przewodników i apt-get upgrade openssl=== apt-get upgradespowoduje to zastosowanie wszystkich poprawek bezpieczeństwa wymaganych przez twój komputer. Cudownie, chyba że wyraźnie bazujesz gdzieś na starej wersji pakietu.

Jest to minimalna czynność wymagana na Ubuntu 12.04 LTS z uruchomionym Apache 2:

  • Przejdź pod ten adres i udowodnij, że masz lukę. Powinieneś użyć BEZPOŚREDNIEGO ZEWNĘTRZNEGO ADRESU SWOJEGO SERWERA INTERNETOWEGO. Jeśli używasz modułu równoważenia obciążenia (na przykład ELB), możesz nie kontaktować się bezpośrednio z serwerem WWW.

  • Uruchom następującą 1 linijkę, aby zaktualizować pakiety i uruchomić ponownie. Tak, widziałem wszystkie przewodniki mówiące, że powinieneś mieć znacznik czasu później niż 4 kwietnia 2014 r. Nie wydaje mi się, że tak jest.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Upewnij się, że masz zainstalowane odpowiednie wersje pakietów i jeszcze raz sprawdź swój serwer pod kątem luki.

Kluczowe pakiety są następujące: ustaliłem te informacje za pomocą poniższego polecenia, a następnie zredagowałem cruft (nie musisz wiedzieć tyle o stanie moich komputerów). 

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12NIE powinien zawierać luki w zabezpieczeniach. Upewnij się, że tak jest, wchodząc ponownie na poniższą stronę internetową i testując serwer WWW.

http://filippo.io/Heartbleed/

Adrian
źródło
2
Używanie strony zewnętrznej w celu udowodnienia podatności na serwerze wydaje mi się złym podejściem.
Rinzwind
Zewnętrzne skrypty do testowania podatności stają się obecnie coraz bardziej powszechne. Robi dokładnie to, co robi wewnętrzny skrypt, połączenie jest właśnie inicjowane z zewnętrznego serwera WWW. Możesz odwiedzić strony takie jak WhiteHatSecurity.com, aby zobaczyć przykład programu, który inicjuje wszystkie połączenia zdalnie. Są przypadki, w których to nie poleciałoby, na przykład testowanie podatności sieci, ale testowanie skierowanego do przodu serwera WWW (którym zazwyczaj będzie serwer SSL) jest prawie idealne.
Adrian
Po co instalować pakiet, jeśli jest aktualizowany?
Braiam
1
apt-get install openssl libssl1.0.0zrobił to dla mnie. Uruchomione openssl version -ateraz pokazuje:built on: Mon Apr 7 20:33:29 UTC 2014
górne
„Zewnętrzne skrypty do testowania podatności stają się coraz bardziej powszechne”, co otwiera możliwość nadużywania mojego systemu przez tę zewnętrzną stronę: wystarczy, że się dowie, że zawiedzie i zhakuje mój system, zanim go załatam. Nie, to nie jest właściwy sposób. (i tak, hostuję własne strony z apache i openssl).
Rinzwind
11

Zauważyłem tutaj wielu komentatorów, którzy pilnie potrzebują pomocy. Postępują zgodnie z instrukcjami, aktualizują się, ponownie uruchamiają i nadal są podatne na ataki podczas korzystania z niektórych testowych stron internetowych.

Musisz sprawdzić, aby upewnić się, że nie masz wstrzymanych pakietów, takich jak libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Aby je uaktualnić apt-mark unhold libssl1.0.0(na przykład). Następnie upgrade: apt-get upgrade -V. Następnie uruchom ponownie usługi, których dotyczy problem.

Domino
źródło