SpaceRat
11.04.2014, 12:09
OpenSSL an sich
Die HDMU-sh4-Images verwenden eine Version von OpenSSL, die nicht vom Heartbleed-Bug betroffen ist (0.9.8)
OpenSSH
OpenSSH ist generell nicht betroffen
Web-Interface
Ich habe das OpenWebif negativ auf den heartbleed-Bug geprüft, d.h. es ist ebenfalls nicht betroffen. Ich gehe für das alte Webinterface ebenfalls davon aus, daß es nicht betroffen ist, da schlußendlich Punkt 1 greift.
OpenVPN
OpenVPN ist ebenfalls gegen eine nicht betroffene Version von OpenSSL gebaut.
Auf dem Feed befindet sich über dies inzwischen eine aktualisierte Version 2.3.3 von OpenVPN.
oscam mit SSL-webif
Das oscam SSL-Webinterface ist ebenfalls sicher, weil es die nicht betroffene OpenSSL-Version 0.9.8 nutzt.
Seitens der HDMU-sh4-Images ist also m.E. nichts zu befüchten.
Vollständige Entwarnung kann aber trotzdem nicht gegeben werden:
Die Gegenstellen eventueller OpenVPN-Netze können natürlich trotzdem betroffen sein und die privaten Zertifikate/Keys verraten haben. Dies gilt insbesondere für gefreezte Fritz!Boxen, da auf diesen OpenSSL 1.0.1-1.0.1f verwendet werden konnte.
Besonders heimtückisch sind aber auch alle anderen unixoiden Gegenstellen, da praktisch kaum eine Distribution saubere Programm-Versionen benutzt, sondern einen unsäglichen Mix aus Uralt-Versionen plus Backports (Auf die Uraltversion zurückportierte Fixes). Dort kann man dann nicht einmal sicher sein, daß OpenSSL != 1.0.1-1.0.1f sicher ist, da die fehlerhafte Heartbeat-Funktion auch auf ältere Versionen zurückportiert worden sein könnte.
An allen Einfallstoren hochgradig gefährdet sind derzeit hingegen alle Images "Based on OpenPLi 4.0", sofern diese - wie das originale OpenPLi 4.0 - OpenSSL 1.0.1e verwenden.
Auf allen diesen Images wären damit die Sicherheit von OpenVPN und den WebInterfaces (incl. oscam) keinen Pfifferling mehr wert!
- - - Aktualisiert - - -
Geeignete Sicherheitsmaßnahmen, wenn Eure OpenVPN-Gegenstelle(n) vom Heartbleed-Bug betroffen waren/sind:
Solange nicht sicher ist, daß eine Gegenstelle gefixt ist, sollte keine Verbindung mehr zu ihr aufgebaut werden.
Sobald eine Gegenstelle gefixt ist, müssen die Zertifikate und Keys erneuert werden, da die alten kompromittiert worden sein könnten. Ein Nachweis darüber ist nicht möglich.
Sicher betroffen sind Gegenstellen dann, wenn sie
OpenVPN 2.3-rc2-I001 bis OpenVPN 2.3.2-I003 für Windows verwendet haben (Enthalten OpenSSL 1.0.1 bis 1.0.1f)
Auf Fritz!Boxen mit OpenSSL 1.0.1 liefen
Ob OpenSSL 1.0.1 verwendet wird, läßt sich wie folgt ermitteln:
cat /etc/.config | grep FREETZ_OPENSSL_SHLIB_VERSION
Die Ausgabe sollte dann in etwa so aussehen:
root@fritz:/etc$ cat /etc/.config | grep FREETZ_OPENSSL_SHLIB_VERSION
FREETZ_OPENSSL_SHLIB_VERSION="0.9.8"
Steht dort statt 0.9.8 eine 1.0.1, dann ist die Fritz!Box definitiv betroffen, sofern sie nicht bereits mit trunk 11932 oder neuer neu gebaut wurde. In diesem Fall ist sie es aber trotzdem möglicher Weise vorher gewesen!
Auf sonstigen Systemen mit OpenSSL 1.0.1 laufen oder liefen
Die Version von OpenSSL kann mittels
openssl version
geprüft werden.
Die Ausgabe sollte lauten:
OpenSSL 1.0.1g 7 Apr 2014
oder eben eine deutlich ältere Version aus der Reihe 0.9.7, 0.9.8 oder 1.0.0, wobei in diesem Fall trotzdem noch Backports des Bugs enthalten sein könnten.
Allerdings gilt auch hier:
Das System könnte in den letzten Tagen bereits gefixt worden sein.
Im Zweifelsfall sollte immer
1. Erst überprüft werden, ob das System jetzt sicher ist.
2. Wenn 1. erfüllt ist, sollten neue Zertifikate erstellt werden
Die HDMU-sh4-Images verwenden eine Version von OpenSSL, die nicht vom Heartbleed-Bug betroffen ist (0.9.8)
OpenSSH
OpenSSH ist generell nicht betroffen
Web-Interface
Ich habe das OpenWebif negativ auf den heartbleed-Bug geprüft, d.h. es ist ebenfalls nicht betroffen. Ich gehe für das alte Webinterface ebenfalls davon aus, daß es nicht betroffen ist, da schlußendlich Punkt 1 greift.
OpenVPN
OpenVPN ist ebenfalls gegen eine nicht betroffene Version von OpenSSL gebaut.
Auf dem Feed befindet sich über dies inzwischen eine aktualisierte Version 2.3.3 von OpenVPN.
oscam mit SSL-webif
Das oscam SSL-Webinterface ist ebenfalls sicher, weil es die nicht betroffene OpenSSL-Version 0.9.8 nutzt.
Seitens der HDMU-sh4-Images ist also m.E. nichts zu befüchten.
Vollständige Entwarnung kann aber trotzdem nicht gegeben werden:
Die Gegenstellen eventueller OpenVPN-Netze können natürlich trotzdem betroffen sein und die privaten Zertifikate/Keys verraten haben. Dies gilt insbesondere für gefreezte Fritz!Boxen, da auf diesen OpenSSL 1.0.1-1.0.1f verwendet werden konnte.
Besonders heimtückisch sind aber auch alle anderen unixoiden Gegenstellen, da praktisch kaum eine Distribution saubere Programm-Versionen benutzt, sondern einen unsäglichen Mix aus Uralt-Versionen plus Backports (Auf die Uraltversion zurückportierte Fixes). Dort kann man dann nicht einmal sicher sein, daß OpenSSL != 1.0.1-1.0.1f sicher ist, da die fehlerhafte Heartbeat-Funktion auch auf ältere Versionen zurückportiert worden sein könnte.
An allen Einfallstoren hochgradig gefährdet sind derzeit hingegen alle Images "Based on OpenPLi 4.0", sofern diese - wie das originale OpenPLi 4.0 - OpenSSL 1.0.1e verwenden.
Auf allen diesen Images wären damit die Sicherheit von OpenVPN und den WebInterfaces (incl. oscam) keinen Pfifferling mehr wert!
- - - Aktualisiert - - -
Geeignete Sicherheitsmaßnahmen, wenn Eure OpenVPN-Gegenstelle(n) vom Heartbleed-Bug betroffen waren/sind:
Solange nicht sicher ist, daß eine Gegenstelle gefixt ist, sollte keine Verbindung mehr zu ihr aufgebaut werden.
Sobald eine Gegenstelle gefixt ist, müssen die Zertifikate und Keys erneuert werden, da die alten kompromittiert worden sein könnten. Ein Nachweis darüber ist nicht möglich.
Sicher betroffen sind Gegenstellen dann, wenn sie
OpenVPN 2.3-rc2-I001 bis OpenVPN 2.3.2-I003 für Windows verwendet haben (Enthalten OpenSSL 1.0.1 bis 1.0.1f)
Auf Fritz!Boxen mit OpenSSL 1.0.1 liefen
Ob OpenSSL 1.0.1 verwendet wird, läßt sich wie folgt ermitteln:
cat /etc/.config | grep FREETZ_OPENSSL_SHLIB_VERSION
Die Ausgabe sollte dann in etwa so aussehen:
root@fritz:/etc$ cat /etc/.config | grep FREETZ_OPENSSL_SHLIB_VERSION
FREETZ_OPENSSL_SHLIB_VERSION="0.9.8"
Steht dort statt 0.9.8 eine 1.0.1, dann ist die Fritz!Box definitiv betroffen, sofern sie nicht bereits mit trunk 11932 oder neuer neu gebaut wurde. In diesem Fall ist sie es aber trotzdem möglicher Weise vorher gewesen!
Auf sonstigen Systemen mit OpenSSL 1.0.1 laufen oder liefen
Die Version von OpenSSL kann mittels
openssl version
geprüft werden.
Die Ausgabe sollte lauten:
OpenSSL 1.0.1g 7 Apr 2014
oder eben eine deutlich ältere Version aus der Reihe 0.9.7, 0.9.8 oder 1.0.0, wobei in diesem Fall trotzdem noch Backports des Bugs enthalten sein könnten.
Allerdings gilt auch hier:
Das System könnte in den letzten Tagen bereits gefixt worden sein.
Im Zweifelsfall sollte immer
1. Erst überprüft werden, ob das System jetzt sicher ist.
2. Wenn 1. erfüllt ist, sollten neue Zertifikate erstellt werden