Wie man den Heartbleed-Fehler (CVE-2014-0160) in OpenSSL patchen kann?

152

Seit heute wurde ein Fehler in OpenSSL gefunden, der sich auf die Versionen 1.0.1 through 1.0.1f ( inklusive) und 1.0.2-beta .

Seit Ubuntu 12.04 sind wir alle anfällig für diesen Fehler. Um diese Sicherheitsanfälligkeit zu beheben, sollten betroffene Benutzer auf OpenSSL 1.0.1g aktualisieren.

Wie kann jeder betroffene Benutzer dieses Update jetzt anwenden ? ?

?     
Lucio 08.04.2014, 00:17
quelle

6 Antworten

141

Sicherheitsaktualisierungen sind für 12.04, 12.10, 13.10 und 14.04 verfügbar siehe Ubuntu Sicherheitshinweis USN-2165-1 .

Zuerst müssen Sie die verfügbaren Sicherheitsupdates anwenden, zum Beispiel indem Sie

ausführen
sudo apt-get update
sudo apt-get upgrade

über die Befehlszeile.

Vergessen Sie nicht, die Dienste (HTTP, SMTP usw.), die die betroffene OpenSSL-Version verwenden, neu zu starten , andernfalls sind Sie immer noch anfällig. Siehe auch Heartbleed: Was ist das und was ist es? Optionen, um es zu verringern? auf Serverfault.com.

Der folgende Befehl zeigt (nach einem Upgrade) alle Dienste an, die neu gestartet werden müssen:

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

Danach brauchen Sie um alle SSL-Schlüssel des Servers zu regenerieren , dann prüfen Sie, ob Ihre Schlüssel durchgesickert sind. In diesem Fall könnten Angreifer vertrauliche Informationen von Ihren Servern abgerufen haben.

    
Florian Diesch 08.04.2014, 00:46
quelle
71

Der Fehler ist bekannt als Heartbleed .

Bin ich verletzlich?

Im Allgemeinen sind Sie betroffen, wenn Sie irgendwann einen Server ausführen, für den Sie einen SSL-Schlüssel generiert haben. Die meisten Endnutzer sind nicht (direkt) betroffen; zumindest verwenden Firefox und Chrome kein OpenSSL. SSH ist nicht betroffen. Die Verteilung von Ubuntu-Paketen ist nicht betroffen (sie beruht auf GPG-Signaturen).

Sie sind verwundbar, wenn Sie einen Server mit OpenSSL-Versionen 1.0-1.0.1f ausführen (mit Ausnahme von Versionen, die seit der Entdeckung des Fehlers gepatcht wurden). Die betroffenen Ubuntu-Versionen sind 11,10 bis 14,04 vertrauenswürdige Pre-Releases. Es ist ein Implementierungsfehler, kein Fehler im Protokoll, daher sind nur Programme betroffen, die die OpenSSL-Bibliothek verwenden. Wenn Sie ein Programm mit der alten 0.9.x-Version von OpenSSL verknüpft haben, ist es nicht betroffen. Betroffen sind nur Programme, die die OpenSSL-Bibliothek zur Implementierung des SSL-Protokolls verwenden. Programme, die OpenSSL für andere Dinge verwenden, sind nicht betroffen.

Wenn Sie einen anfälligen Server im Internet betrieben haben, betrachten Sie ihn als kompromittiert, wenn Ihre Protokolle seit der Ankündigung am 2014-04-07 keine Verbindung mehr aufweisen. (Dies setzt voraus, dass die Sicherheitsanfälligkeit nicht vor ihrer Ankündigung ausgenutzt wurde.) Wenn Ihr Server nur intern verfügbar gemacht wurde, hängt es von den anderen Sicherheitsmaßnahmen ab, ob Sie die Schlüssel ändern müssen.

Was ist der Einfluss?

Der Fehler erlaubt jedem Client , der eine Verbindung zu Ihrem SSL-Server herstellen kann, um ungefähr 64 KB Speicher vom Server abzurufen. Der Client muss in keiner Weise authentifiziert werden. Durch Wiederholung des Angriffs kann der Client bei aufeinanderfolgenden Versuchen verschiedene Speicherbereiche löschen.

Einer der kritischen Daten, die der Angreifer möglicherweise abrufen kann, ist der private SSL-Schlüssel des Servers. Mit diesen Daten kann der Angreifer die Identität Ihres Servers annehmen.

Wie kann ich auf einem Server wiederherstellen?

  1. Nehmen Sie alle betroffenen Server offline. So lange sie ausgeführt werden, können kritische Daten verloren gehen.

  2. Aktualisieren Sie das libssl1.0.0 -Paket und stellen Sie sicher, dass alle betroffenen Server neu gestartet werden.
    Sie können überprüfen, ob die betroffenen Prozesse noch mit '' grep 'libssl. (gelöscht)' / proc / / maps '

  3. ausgeführt werden
  4. Generiere neue Schlüssel . Dies ist notwendig, da der Fehler es einem Angreifer ermöglicht haben könnte, den alten privaten Schlüssel zu erhalten. Befolgen Sie die gleiche Prozedur, die Sie ursprünglich verwendet haben.

    • Wenn Sie Zertifikate verwenden, die von einer Zertifizierungsstelle signiert wurden, senden Sie Ihre neuen öffentlichen Schlüssel an Ihre Zertifizierungsstelle. Wenn Sie das neue Zertifikat erhalten haben, installieren Sie es auf Ihrem Server.
    • Wenn Sie selbstsignierte Zertifikate verwenden, installieren Sie sie auf Ihrem Server.
    • Wie auch immer, verschieben Sie die alten Schlüssel und Zertifikate aus dem Weg (aber löschen Sie sie nicht, nur sicherstellen, dass sie nicht mehr benutzt werden).
  5. Jetzt, da Sie neue kompromisslose Schlüssel haben, können Sie Ihren Server wieder online schalten .

  6. Widerrufen Sie die alten Zertifikate.

  7. Schadensbewertung : Möglicherweise wurden Daten, die sich im Speicher eines Prozesses befanden, der SSL-Verbindungen bedient, möglicherweise durchgesickert. Dies kann Benutzerkennwörter und andere vertrauliche Daten enthalten. Sie müssen herausfinden, was diese Daten waren.

    • Wenn Sie einen Dienst ausführen, der die Kennwortauthentifizierung ermöglicht, sollten die Kennwörter von Benutzern, die seit der Ankündigung der Sicherheitsanfälligkeit eine Verbindung hergestellt haben, als kompromittiert betrachtet werden. (Ein wenig vorher, weil das Passwort für einige Zeit im Speicher nicht verwendet wurde.) Überprüfen Sie Ihre Protokolle und ändern Sie die Kennwörter aller betroffenen Benutzer.
    • Außerdem werden alle Sitzungscookies ungültig, da sie möglicherweise kompromittiert wurden.
    • Clientzertifikate sind nicht kompromittiert.
    • Alle Daten, die kurz vor der Sicherheitsanfälligkeit ausgetauscht wurden, sind möglicherweise im Speicher des Servers verblieben und wurden möglicherweise an einen Angreifer weitergegeben.
    • Wenn jemand eine alte SSL-Verbindung aufgezeichnet und die Schlüssel Ihres Servers abgerufen hat, kann er sein Transkript jetzt entschlüsseln. (Es sei denn PFS wurde sichergestellt - wenn Sie nicht wissen, war es nicht.)

Wie kann ich auf einem Client wiederherstellen?

Es gibt nur wenige Situationen, in denen Clientanwendungen betroffen sind. Das Problem auf der Serverseite ist, dass jeder sich mit einem Server verbinden und den Fehler ausnutzen kann. Um einen Client auszunutzen, müssen drei Bedingungen erfüllt sein:

  • Das Client-Programm hat eine fehlerhafte Version der OpenSSL-Bibliothek verwendet, um das SSL-Protokoll zu implementieren.
  • Der Client ist mit einem böswilligen Server verbunden. (Wenn Sie beispielsweise eine Verbindung zu einem E-Mail-Anbieter hergestellt haben, ist dies kein Problem.) Dies musste geschehen, nachdem der Serverbesitzer auf die Sicherheitsanfälligkeit aufmerksam wurde, vermutlich nach dem 2014-04-07.
  • Der Clientprozess hatte vertrauliche Daten im Arbeitsspeicher, die nicht mit dem Server geteilt wurden. (Wenn Sie also zum Herunterladen einer Datei wget gerade ausgeführt haben, sind keine Daten verloren gegangen.)

Wenn Sie dies zwischen dem 07.04.2014, dem abendlichen UTC, und dem Upgrade Ihrer OpenSSL-Bibliothek getan haben, berücksichtigen Sie, dass alle Daten im Speicher des Client-Prozesses kompromittiert wurden.

Referenzen

Gilles 08.04.2014 12:02
quelle
40

Um zu sehen, welche OpenSSL-Version unter Ubuntu installiert ist:

dpkg -l | grep openssl

Wenn Sie die Ausgabe der folgenden Version sehen, sollte Patch für CVE-2014-0160 enthalten sein.

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

Betrachtet man Pfandrecht , zeigt es an, welche Arten von Fehlern behoben wurden:

...
 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 08.04.2014 08:40
quelle
17

Wenn Ihre apt-get-Repositorys keine vorkompilierte 1.0.1g OpenSSL -Version enthalten, laden Sie einfach Quellen von der offiziellen Website herunter und kompilieren Sie sie.

Unterhalb der einzelnen Befehlszeile zum Kompilieren und Installieren der letzten openssl Version.

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

Ersetzen Sie die alte openssl-Binärdatei durch einen neuen über einen Symlink.

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

Ihr seid alle gut!

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

Vgl. Blogpost .

Hinweis: Wie im Blog-Beitrag angegeben, wird diese Problemumgehung "Nginx und Apache Server, die mit 1.0.1g openSSL-Quellen neu kompiliert werden müssen, nicht beheben."

    
Quentin Rousseau 08.04.2014 04:18
quelle
12

Für diejenigen, die kein serverweites Paket-Upgrade durchführen möchten. Ich habe heute einige dieser Handbücher gelesen und apt-get upgrade openssl === apt-get upgrade , damit werden alle von Ihrem Computer benötigten Sicherheitsfixes angewendet. Wunderbar, es sei denn, Sie stützen sich explizit auf eine alte Paketversion.

Dies ist die minimale Aktion, die für Ubuntu 12.04 LTS mit Apache 2 erforderlich ist:

  • Gehen Sie zu dieser Adresse und beweisen Sie, dass Sie die Sicherheitsanfälligkeit haben. Sie sollten die DIREKTE EXTERNE ADRESSE IHRES WEBSERVERS verwenden. Wenn Sie einen Loadbalancer (z. B. ELB) verwenden, kontaktieren Sie möglicherweise Ihren Webserver nicht direkt.

  • Führen Sie den folgenden 1 Liner aus, um die Pakete zu aktualisieren und neu zu starten. Ja, ich habe alle Guides gesehen, die sagen, dass du einen Zeitstempel später als am 4. April 2014 haben solltest, das scheint mir nicht der Fall zu sein.

    apt-get update & amp; & amp; apt-get install openssl libssl1.0.0 & amp; & amp; /etc/init.d/apache2 neustart

  • Stellen Sie sicher, dass Sie geeignete Paketversionen installiert haben, und überprüfen Sie Ihren Webserver erneut auf die Sicherheitsanfälligkeit.

Die Schlüsselpakete sind wie folgt, ich habe diese Informationen mit dem unten stehenden Befehl bestimmt und dann die Gruft weggeschnitten (Sie müssen nicht viel über den Zustand meiner Maschinen wissen).

$ 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.12 sollte die Sicherheitsanfälligkeit NICHT enthalten. Stellen Sie sicher, dass dies der Fall ist, indem Sie erneut auf die unten stehende Website gehen und Ihren Webserver testen.

Pfandrecht

    
Adrian 08.04.2014 23:56
quelle
11

Ich habe viele Kommentatoren hier bemerkt, die dringend Hilfe brauchen. Sie befolgen die Anweisungen und aktualisieren und starten neu und sind weiterhin anfällig, wenn sie einige der Test-Websites verwenden.

Sie müssen sicherstellen, dass keine Pakete in der Warteschleife sind, wie zum Beispiel 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.

Um diese apt-mark unhold libssl1.0.0 (zum Beispiel) zu aktualisieren. Dann upgrade: apt-get upgrade -V . Starten Sie dann betroffene Dienste neu.

    
Domino 08.04.2014 19:51
quelle

Tags und Links