Anfechtung der Sicherheitslücke CVE-2014-2734

Geschrieben von emboss am 9.5.2014
Übersetzt von Quintus

Wir sind vor kurzem über eine Sicherheitslücke informiert worden, die als CVE-2014-2734 veröffentlicht wurde. Aufgrund unserer unten dargelegten detaillierten Analyse glauben wir jedoch nicht, dass Ruby verwundbar ist.

Diese Sicherheitslücke kann es einem Angreifer ermöglichen, beliebige Wurzelzertifikate zu fälschen, wobei er effektiv den privaten Schlüssel des Originalzertifikats durch seinen eigenen ersetzt.

Proof of Concept

Folgend finden Sie unsere Analyse von CVE-2014-2734; wir konnten den ursprünglichen Nachweis auf diesen unserer Meinung nach den Kern des Problems beschreibenden Code reduzieren:

require 'openssl'

forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)

resigned_cert.verify(key) #=> true

Es mag überraschend erscheinen, dass X590Certificate#verify den Wert true zurückgibt. Das Originalzertifikat kann eine Subject Public Key Info enthalten, die auf den ursprünglichen öffentlichen Schlüssel verweist, der sich von forge_key unterscheidet. Augenscheinlich handelt es sich bei dem Schlüsselpaar, mit dem das Zertifikat neu signiert wurde, nicht mehr um das in der Subject Public Key Info referenzierte Schlüsselpaar. Weshalb also ergibt #verify den Wert true?

Wie Schlüssel verifiziert werden

X509Certificate#verify bedient sich OpenSSLs X509_verify-Funktion, welche wiederum an ASN1_item_verify delegiert. Diese beiden Funktionen stellen die Gültigkeit der Signatur anhand des angegebenen öffentlichen Schlüssels sicher. Sie verifizieren jedoch nicht, ob der angegebene Schlüssel mit demjenigen, der im Zertifikat referenziert wird, übereinstimmt. Daraus folgt, dass die Rückgabe von true in diesem Szenario das für X590Certificate#verify erwartete Verhalten ist. Das Auslassen dieser Prüfung hat keine wesentlichen Auswirkungen auf die Gesamtsicherheit des X.590-Vertrauensmodells.

Abschnitt 4.1.1.3 von RFC 5280 stellt ausdrücklich fest, dass die CA bei der Berechnung einer Zertifikatssignatur die Richtigkeit der im Zertifikat enthaltenen Informationen zu bestätigen hat. Zwar wird dieses Prinzip durch den obigen Beispielcode verletzt, jedoch stellt dies keine Bedrohung der Sicherheit da. Ein in dieser Weise gefälschtes oder verändertes Zertifikat kann nicht benutzt werden, solange niemand Sie dazu bringt, einem dieses Prinzip verletzenden Zertifikat zu vertrauen.

Potenzielle Risiken

Es gibt zwei Fälle zu beachten:

Neusignierung eines Wurzelzertifikats

Als Nutzer vertrauen wir den Wurzelzertifikaten uneingeschränkt. Selbst dann, wenn sie keine gültigen Informationen enthalten, hat dies auf ihren Status als öffentlich beglaubigtes Wurzelzertifikat keinerlei Einfluss. Es handelt sich um vorkonfigurierte Werte in den Vertrauensdatenbanken unserer Browser und Betriebssysteme, durch ihre bloße Verarbeitung kommt ihr Status als gültiger Vertrauensanker zustande. Beispielsweise überprüft nicht einmal OpenSSL selbst standardmäßig die Signatur eines selbstsignierten Wurzelzertifikats aus denselben Gründen, vgl. die Dokumentation zu X509_V_FLAG_CHECK_SS_SIGNATURE.

Ein neu signiertes Wurzelzertifikat wird zu einem de facto selbstsignierten Zertifikat (wenn auch mit falscher Subject Public Key Info). Dies ist nicht gefährlicher als ein gewöhnliches selbstsigniertes Wurzelzertifikat. Tatsächlich ist es jedermann möglich, ein selbstsigniertes Wurzelzertifikat zu erstellen, das mit einem gültigen Wurzelzertifikat vollständig übereinstimmt — außer in der Signatur. Da wir Wurzelzertifikaten bereits durch Besitz vertrauen, ist ein derartig verändertes Zertifikat ohne die explizite Zustimmung des Clients zum Vertrauen bedeutungslos.

Neusignierung eines Zwischen- oder Blattzertifikats

Auch die Neusignierung eines Nicht-Wurzel-Zertifikats verletzt nicht das X.590-Vertrauensmodell. Zwar besitzen wir diese Zertifikate üblicherweise nicht im Voraus, jedoch würde deren Fälschung beim Pfadvalidierungsprozess auffallen. Hierbei wird die Signatur jedes Nicht-Wurzel-Zertifikats anhand des öffentlichen Schlüssels des beglaubigenden Zertifikats überprüft; an irgendeinem Punkt der Zertifikatskette würde eine Fälschung zwingend in der Form einer ungültigen Zertifikatssignatur auftreten.

Zusammenfassung

Unterm Strich glauben wir, dass sich X509Certificate#verify so verhält wie erwartet. Unabhängig davon sind andere bereits zum selben Ergebnis gekommen, weshalb wir CVE-2014-2734 angefochten und seinen Widerruf beantragt haben. Sie können die vollständige Analyse und das ursprüngliche Proof of Concept samt Kommentaren ebenfalls einsehen.