← Alle Blogartikel
Infrastruktur

OpenSSL 2022: Zwei X.509-Pufferüberläufe in der Zertifikatsprüfung

CVE-2022-3602 und CVE-2022-3786 betrafen die Prüfung bestimmter X.509-E-Mail-Adressbeschränkungen in OpenSSL 3.0.

Die OpenSSL-Meldung vom 1. November 2022

Am 1. November 2022 veröffentlichte das OpenSSL-Projekt die Sicherheitsmeldung zu CVE-2022-3602 und CVE-2022-3786. Beide Schwachstellen betrafen die Prüfung von E-Mail-Adressen in X.509-Zertifikaten unter OpenSSL 3.0.0 bis 3.0.6. Die korrigierte Version war OpenSSL 3.0.7.

Bei CVE-2022-3602 konnte ein vier Byte großer Stack-Pufferüberlauf auftreten. OpenSSL nannte einen Prozessabsturz und unter bestimmten Voraussetzungen potenziell auch Codeausführung als mögliche Folgen. Bei CVE-2022-3786 konnte die Überlänge variabel sein; die offizielle Meldung beschrieb als Auswirkung einen Absturz und damit eine Dienstverweigerung.

Beide wurden in der finalen Sicherheitsmeldung als High eingestuft. CVE-2022-3602 war vor der Veröffentlichung zunächst als Critical angekündigt worden. Weitere Analyse der notwendigen Voraussetzungen und vorhandener Schutzmechanismen führte zur Herabstufung. Die CVSS-Einstufung beschreibt Schwere und Angriffsbedingungen; sie ist keine Garantie, dass ein Angriff in jeder TLS-Verbindung möglich ist.

Welche Voraussetzungen relevant waren

Der Fehler lag bei der X.509-Namensbeschränkungsprüfung. Die Verarbeitung musste die entsprechende Zertifikatsprüfung erreichen; bei CVE-2022-3602 nannte OpenSSL zusätzliche Voraussetzungen, etwa ein von einer Zertifizierungsstelle signiertes schädliches Zertifikat oder eine Anwendung, die trotz eines fehlgeschlagenen Vertrauenspfads weiterprüft.

Das konkrete Risiko hing also von der Rolle und Konfiguration der Anwendung ab. Ein TLS-Client konnte unter bestimmten Umständen durch eine Verbindung zu einem bösartigen Server betroffen sein; ein TLS-Server insbesondere dann, wenn er Client-Zertifikate anforderte. Daraus folgt nicht, dass jede HTTPS-Verbindung oder jede OpenSSL-Version betroffen war.

Was Betreiber daraus mitnehmen sollten

  • Prüfen Sie, ob OpenSSL 3.0.0 bis 3.0.6 in einem Dienst, Container oder Produkt eingesetzt wurde, und aktualisieren Sie auf 3.0.7 oder eine vom Anbieter korrigierte Version.
  • Verlassen Sie sich bei Betriebssystempaketen nicht nur auf die Upstream-Versionsnummer. Distributionen können Sicherheitskorrekturen zurückportieren und eigene Paketmeldungen veröffentlichen.
  • Prüfen Sie neben Webservern auch Clients, Mailserver, Appliances und Anwendungen, die Zertifikatsprüfung selbst durchführen.
  • Halten Sie Vorankündigungen von Sicherheitsmeldungen vertraulich und warten Sie für die endgültige Risikobewertung auf die veröffentlichte technische Advisory. Die OpenSSL-Einstufung zeigt, dass sich Bewertungen vor vollständiger Analyse ändern können.

Der Vorfall veranschaulicht ein dauerhaftes Architekturproblem: Kryptografische Bibliotheken sind Vertrauensanker, bestehen aber aus komplexem, oft speicherunsicherem Code. Versionsinventar, schnelle Updates und sichere Speicherbehandlung müssen deshalb gemeinsam geplant werden.

Quellen