FREAK: OpenSSL-Sicherheitslücke (CVE-2015-0204)
Im Januar 2015 befasste sich die Red Hat Product Security mit der CVE-2015-0204 Sicherheitslücke in OpenSSL mit dem Advisory: RHSA-2015-0066 und RHSA-2015-0800. Die Auswirkungen dieser Sicherheitslücke wurden als moderat klassifiziert. Diese Sicherheitslücke wird in den Medien nun FREAK genannt.
Hintergrundinformationen
OpenSSL-Clients akzeptierten unsichere Schlüssel (der EXPORT-Klasse), selbst wenn der Client diese nicht ursprünglich angefordert hat. Dies kann bei einem sogenannten Man-in-the-Middle-Angriff ausgenutzt werden, bei dem die Client-Anfrage nach einem standardmäßigen Schlüssel abgefangen wird und vom Server stattdessen ein Schlüssel der EXPORT-Klasse angefordert wird. Der Client akzeptiert den unsicheren Schlüssel, sodass der Angreifer dazu in der Lage ist, die Kommunikation zwischen Client und Server zu entschlüsseln.
Auswirkungen
Zwar ist die Verwendung von Chiffren der EXPORT-Klasse standardmäßig in OpenSSL, das in den neuesten Versionen Red Hat Enterprise Linux (5.11, 6.6 und 7.1) integriert ist, deaktiviert, es kann jedoch von Applikationen aktiviert werden, welche die OpenSSL-Bibliothek nutzen. Aus diesem Grund werden alle Red Hat Enterprise Linux 5, 6 und 7 Systeme als betroffen betrachtet, einschließlich der Server-, Workstation-, Desktop- und HPC-Node-Varianten, sofern diese nicht die korrigierte Version der OpenSSL-Pakete installiert haben.
Die in Red Hat Enterprise Linux 5 enthaltene Version von openssl097a ist ebenfalls betroffen. Da sich Red Hat Enterprise Linux 5 jetzt in der Produktionsphase 3 des Lebenszyklus für Support und Wartung befindet, während der lediglich kritische Sicherheits-Advisorys bereitgestellt werden, ist derzeit nicht geplant, diese Sicherheitslücke in zukünftigen Aktualisierungen zu beheben.
Lösung
Um eine mögliche Ausnutzung der Sicherheitslücke von OpenSSL-Clients zu verhindern, installieren Sie die aktualisierten OpenSSL-Pakete, die in diesem Advisory bereitgestellt werden: RHSA-2015-0066 und RHSA-2015-0800.
Installieren Sie die Aktualisierungen mithilfe des yum Paketmanagers wie folgt:
yum update
Führen Sie den folgenden Befehl aus, um nur die OpenSSL-Pakete und deren Abhängigkeiten zu installieren:
yum update openssl
Hinweis: Um sicherzustellen, dass nicht gepatchte Clients, die sich mit einem OpenSSL-Server verbinden, nicht über diese Sicherheitslücke ausgenutzt werden können, sollten Sie die Chiffren der EXPORT-Klasse auf dem Server deaktivieren wie im nachfolgenden Abschnitt "Vorbeugung" beschrieben.
Hinweis: Ein Neustart des Systems nach der Aktualisierung ist die sicherste Methode, um zu gewährleisten, dass alle betroffenen Dienste die aktualisierte ssl-Bibliothek verwenden. Lesen Sie den nachfolgenden Unterabschnitt, falls Sie einen Neustart vermeiden möchten.
Neustarten von Prozessen, damit die Änderungen wirksam werden
Wie bereits erwähnt, ist die einfachste und sicherste Methode die Durchführung eines vollständigen Systemneustarts. Alternativ können Sie lediglich die betroffenen Dienste neu starten. Gehen Sie dazu folgendermaßen vor:
Bestimmen der neu zu startenden Prozesse
Um die betroffenen Dienste aufzulisten, suchen Sie mithilfe des grep-Befehls nach DEL bei Ausführung des Befehls lsof:
# lsof | grep DEL | grep -e crypto -e libssl
sshd 7708 root DEL REG 253,0 139948 /usr/lib64/libcrypto.so.1.0.1e
^^^--- sshd-Dienst
certmonge 7940 root DEL REG 253,0 139948 /usr/lib64/libcrypto.so.1.0.1e
^^^--- certmonger-Dienst
Xorg 7986 root DEL REG 253,0 139948 /usr/lib64/libcrypto.so.1.0.1e
^^^--- Xwindows-Dienst
sshd 8990 root DEL REG 253,0 139948 /usr/lib64/libcrypto.so.1.0.1e
^^^--- verwendet von der SSH-Sitzung mit Bash-Shell
master 7796 root DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
^^^--- postfix-Dienst
qmgr 7809 postfix DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
^^^--- postfix-Dienst
tuned 7866 root DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
^^^--- tuned-Dienst
pickup 9501 postfix DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
^^^--- postfix-Dienst
httpd 9524 root DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
^^^--- httpd-Dienst
httpd 9526 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9527 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9528 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9529 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9530 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9531 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9532 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9533 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9534 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
httpd 9535 apache DEL REG 253,0 140068 /usr/lib64/libssl.so.1.0.1e
Um Dienste neu zu starten, die von chkconfig verwaltet werden:
# service sshd restart
# service certmonger restart
# service postfix restart
# service tuned restart
# service httpd restart
Um Xorg neu zu starten:
# init 3
# lsof | grep DEL | grep -e crypto -e libssl
# init 5
Prüfen Sie die Liste erneut und melden Sie sich ab, um den letzten Eintrag zu entfernen:
# lsof | grep ssl | grep lib | grep DEL
sshd 8990 root DEL REG 253,0 139948 /usr/lib64/libcrypto.so.1.0.1e
^^^--- verwendet von der aktuellen SSH-Sitzung mit Bash-Shell
# logout
Vorbeugung für nicht gepatchte Clients
Um der in diesem Artikel beschriebenen Sicherheitslücke vorzubeugen, können Sie die Chiffren der EXPORT-Klasse in Ihrem Client oder Server auch deaktivieren. Dieses Vorgehen wird für Server insbesondere dann empfohlen, wenn Sie nicht gewährleisten können, dass alle Clients, die sich mit Ihrem Server verbinden, gepatcht wurden.
Deaktivieren von EXPORT-Chiffren in httpd
Um die Verwendung von Chiffren der EXPORT-Klasse durch den httpd Webserver zu verhindern, fügen Sie die Direktive !EXP zur Zeile SSLCipherSuite in der Konfigurationsdatei /etc/httpd/conf.d/ssl.conf hinzu. Zum Beispiel:
SSLCipherSuite HIGH:!aNULL:!MD5:!EXP
Nach Änderung der ssl.conf-Datei müssen Sie den httpd-Dienst neu starten.
# service httpd restart
Comments