Streitfall bezüglich Schwachstelle CVE-2014-2734

Gepostet von emboss am 9. Mai 2014

Wir wurden kürzlich über eine mögliche Sicherheitslücke informiert, die als CVE-2014-2734 veröffentlicht wurde. Basierend auf unserer detaillierten Analyse unten halten wir Ruby jedoch für nicht anfällig.

Diese Schwachstelle könnte einem Angreifer ermöglichen, beliebige Stammzertifikate zu fälschen, indem die Signatur des Zertifikats modifiziert wird, wodurch effektiv der ursprüngliche private Schlüssel des Zertifikats durch einen vom Angreifer gewählten ersetzt wird.

Proof of Concept

Das Folgende ist unsere Analyse von CVE-2014-2734. Wir konnten den ursprünglichen PoC reduzieren, von dem wir glauben, dass er das Wesentliche des Proof of Concept erfasst.

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 überraschen, dass X509Certificate#verify true zurückgibt. Das ursprüngliche Zertifikat kann eine Subject Public Key Info enthalten, die auf den ursprünglichen öffentlichen Schlüssel verweist, welcher sich vom öffentlichen Schlüssel von forge_key unterscheidet. Offensichtlich stimmt das Schlüsselpaar, das zum Neu-Signieren des Zertifikats verwendet wurde, nicht mehr mit dem ursprünglichen öffentlichen Schlüssel überein, auf den in der Subject Public Key Info verwiesen wird. Warum gibt #verify in diesem Fall true zurück?

Wie Schlüssel verifiziert werden

X509Certificate#verify verwendet intern die Funktion X509_verify von OpenSSL, die an ASN1_item_verify delegiert. Diese Funktionen stellen die Gültigkeit der Signatur angesichts des bereitgestellten öffentlichen Schlüssels fest. Sie überprüfen jedoch **nicht**, ob der gegebene Schlüssel tatsächlich mit einem in dem Zertifikat referenzierten öffentlichen Schlüssel des Subjekts übereinstimmt. Das bedeutet, dass die Rückgabe von true in diesem Szenario das erwartete Verhalten für X509Certificate#verify ist. Das Weglassen dieser Prüfung hat keine signifikanten Auswirkungen auf die allgemeine Sicherheit des X.509-Vertrauensmodells.

Abschnitt 4.1.1.3 von RFC 5280 besagt ausdrücklich, dass durch die Berechnung einer Zertifikatssignatur die Zertifizierungsstelle (CA) die Korrektheit der im Zertifikat enthaltenen Informationen bestätigt. Obwohl dieses Prinzip im obigen Beispielcode verletzt wird, stellt es keine Bedrohung für die Sicherheit dar. Ein auf diese Weise gefälschtes oder modifiziertes Zertifikat kann nicht ausgenutzt werden, es sei denn, es gelingt jemandem, Sie davon zu überzeugen, ein Zertifikat, das gegen dieses Prinzip verstößt, explizit zu vertrauen.

Potenzielle Risiken

Es gibt zwei Fälle zu betrachten:

Neu-Signieren eines Stammzertifikats

Als Benutzer vertrauen wir Stammzertifikaten bedingungslos. Selbst wenn sie keine gültigen Informationen enthalten, ist ihr Status als öffentlich anerkannter Stammzertifikat allein das, was sie intakt hält. Sie sind voreingestellte Werte in den Vertrauensspeichern unserer Browser oder Betriebssysteme. Allein der Besitz etabliert ihren Status als gültige Vertrauensanker. OpenSSL selbst prüft beispielsweise standardmäßig nicht die Signatur von selbstsignierten Stammzertifikaten aus den gleichen Gründen, siehe Dokumentation zu X509_V_FLAG_CHECK_SS_SIGNATURE.

Ein neu signiertes Stammzertifikat wird zu einem de-facto "selbstsignierten" Zertifikat (wenn auch mit falscher Subject Public Key Info). Dies ist nicht gefährlicher als ein normales selbstsigniertes Stammzertifikat. Tatsächlich kann jeder selbstsignierte Stammzertifikate erstellen, die vollständig mit denen eines gültigen Stammzertifikats übereinstimmen könnten – mit Ausnahme der Signatur. Da wir Stammzertifikaten lediglich durch Besitz vertrauen, ist ein solches Betrugszertifikat bedeutungslos, ohne die aktive Zustimmung eines Clients, ihm zu vertrauen.

Neu-Signieren eines Zwischen- oder Endzertifikats

Auch das Neu-Signieren eines Nicht-Stammzertifikats verletzt nicht die Sicherheit des X.509-Vertrauensmodells. Obwohl wir diese Art von Zertifikaten normalerweise nicht im Voraus besitzen, würde ihre Fälschung während des Pfadvalidierungsverfahrens erkannt werden. Hier wird die Signatur jedes Nicht-Stammzertifikats mit dem öffentlichen Schlüssel des ausstellenden Zertifikats verifiziert. Irgendwann in der Zertifikatkette würde die Fälschung letztendlich in Form eines ungültigen Zertifikatssignaturwerts erkannt werden.

Schlussfolgerung

Zusammenfassend glauben wir, dass X509Certificate#verify wie erwartet funktioniert. Andere sind unabhängig zu demselben Schluss gekommen, und wir haben daher CVE-2014-2734 angefochten und um dessen Widerruf gebeten. Sie finden unsere vollständige Analyse des ursprünglichen Proof of Concept einschließlich Kommentaren.