Dipl.-Inform. Carsten Eilers

SSLv3 ist für den Padding-Oracle-Angriff anfällig, weil im Standard nicht definiert wird, wie die Padding-Bytes gebildet werden sollen. Die Implementierungen können die Korrektheit des Paddings also auch nicht prüfen. Beim Angriff wird das ausgenutzt, um durch manipulierte Padding-Bytes Teile der verschlüsselten Daten zu ermitteln.

In der TLS-Spezifikation wird der Inhalt der Padding-Bytes definiert, so dass sie auf Korrektheit geprüft werden können. Dadurch wird eine Manipulation durch den Angreifer und damit der Angriff unmöglich gemacht. Da das TLS-Padding eine Untermenge des SSLv3-Paddings ist, ist es technisch möglich, die Dekodier-Funktion von SSLv3 auch für das TLS-Padding zu verwenden. Dabei werden die Padding-Bytes natürlich nicht geprüft, aber so lange alles normal läuft ist das kein Problem. Dazu wird es erst, wenn ein Angriff statt findet, denn dann ist auch TLS für den Poodle-Angriff anfällig.

Erstmals gemeldet wurde diese Möglichkeit von Brian Smith, als Beispiel diente ihm eine alte Version von NSS. Adam Langley hat daraufhin einen Scanner zur Suche nach betroffenen Implementierungen geschrieben und festgestellt, dass einige große Websites von der neuen Schwachstelle betroffen waren.

Bei einer Website konnte Langley schnell herausfinden, dass eine F5-Appliance für die Schwachstelle verantwortlich war, und kontaktierte daraufhin F5. Parallel dazu hat Yngve Pettersen die gleiche Entdeckung gemacht und Adam Langley kontaktiert.

Nachdem F5 Adam Langley mitteilte, dass einige der betroffenen Websites nicht zu ihren Kunden gehören, ging die Suche nach weiteren Verursachern der Schwachstelle weiter. Es musste ja noch mindestens einen Hersteller betroffener Geräte geben. Als nächstes wurde A10 als betroffener Hersteller ermittelt und informiert. Ob es weitere betroffene Systeme gibt ist bisher nicht bekannt.

Inzwischen haben sowohl F5 (Advisory) als auch A10 (Advisory als PDF) Patches veröffentlicht, die die Schwachstelle mit der CVE-ID CVE-2014-8730 korrigieren.

Wie gefährlich ist der Angriff?

Da der Poodle-Angriff darauf angewiesen ist, auf dem Client JavaScript-Code auszuführen, sind im Allgemeinen Webbrowser das Ziel der Angriffe. Um ein Zeichen eines Cookies zu ermitteln sind laut Ivan Ristic 256 Requests nötig, für einen 16 Zeichen langen Cookie 4096 Requests. Zudem ist kein Downgrade auf SSLv3 nötig, so dass dieser Angriff ziemlich praktikabel ist.

Alle Server-Betreiber sollten also prüfen, ob ihre Server betroffen sind. Zur Zeit betrifft das mindestens alle Installationen, die Loadbalancer von F5 oder A10 verwenden, hier gilt es, die bereit stehenden Patches zu installieren. Ob noch weitere Appliances oder auch Server-Implementierungen betroffen sind ist noch nicht bekannt. Nachdem die Schwachstelle jetzt aber öffentlich bekannt ist dürften betroffene Implementierungen schnell auffallen.

Wie kann man Server und Clients testen?

Die Tests der Qualys SSL Labs für Server und Clients berücksichtigen sowohl die ursprüngliche Poodle-Schwachstelle als auch die neue Schwachstelle in den TLS-Implementierungen.

Was ist denn nun noch sicher?

Adam Langley weist zum Abschluss seiner Beschreibung der neuen Schwachstelle noch einmal explizit darauf hin, dass jede TLS-Version unter TLS 1.2 mit einer AEAD Cipher-Suite ("Authenticated Encryption with Associated Data", die Daten werden simultan verschlüsselt und authentifiziert) kryptographisch als gebrochen gilt. Den gleichen Effekt erzielt die Methode "Encrypt-then-MAC" (Erst verschlüsseln, dann den Message Authentication Code zur Authentifizierung berechnen), der in einer Erweiterung (RFC 7366) für TLS spezifiziert wurde.

Zwar ist "kryptographisch gebrochen" nicht gleichbedeutend mit "es sind praktische Angriffe möglich", trotzdem sollte man von Anfang an auf Nummer sicher gehen und als potentiell angreifbar erkannte Verfahren möglichst meiden.

Carsten Eilers