[English]Das Update auf OpenSSL 3.0.7 liegt nun auf den Seiten des Projekts vor. Damit hat das Team der OpenSLL-Entwickler die vor einiger Woche zum 1. November 2022 angekündigte neue Version vor. Aufmerksamkeit erregte die Ankündigung des Updates auf die Version 3.0.7, weil diese eine als kritisch eingestufte Schwachstelle schließen soll. Ganz so kritisch ist das Ganze aber wohl nicht geworden.
Anzeige
Was ist OpenSSL?
OpenSSL ist eine weit verbreitete Code-Bibliothek, die eine sichere Kommunikation über das Internet ermöglicht. OpenSSL umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen sowie das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten (siehe). Wer im Internet surft, eine Website besucht oder auf einen Online-Dienst zugreift, nutzt OpenSSL.
OpenSSL 3.0.7 mit Schwachstellenfix
Im Blog-Beitrag Hinweis: Patch für OpenSSL Schwachstelle zum 1. Nov. 2022 hatte ich ja darauf hingewiesen, dass die neue Version der Bibliothek einen Sicherheitsfix beinhalten soll, der als kritisch eingestuft wird. Nun hat das OpenSSL-Projekt ein Security Advisory vorgelegt, welches Details verrät.
CVE-2022-3602: X.509-E-Mail-Adresse 4-Byte-Pufferüberlauf
Ein Pufferüberlauf kann, insbesondere bei der Überprüfung von Namensbeschränkungen, bei der Überprüfung von X.509-Zertifikaten ausgelöst werden. Dies tritt aber erst nach der Überprüfung der Signatur der Zertifikatskette auf und setzt voraus, dass entweder eine CA das böswillige Zertifikat signiert haben muss oder dass die Anwendung die Zertifikatsprüfung fortsetzt, obwohl sie keinen Pfad zu einem vertrauenswürdigen Aussteller hat. Dieses Problem wurde am 17. Oktober 2022 von Polar Bear an OpenSSL gemeldet.
Ein Angreifer kann eine bösartige E-Mail-Adresse erstellen, um vier Bytes auf dem Stack abzulegen und dann einen Buffer-Overflow auszulösen. In einem TLS-Client kann dies durch die Verbindung zu einem bösartigen Server ausgelöst werden. Bei einem TLS-Server kann dies ausgelöst werden, wenn der Server eine Client-Authentifizierung anfordert und ein bösartiger Client eine Verbindung herstellt. Dieser Pufferüberlauf kann zu einem Absturz führen (was eine Dienstverweigerung verursacht) oder möglicherweise eine Remotecodeausführung ermöglicht.
Viele Plattformen verfügen über Schutzmechanismen gegen einen Stapelüberlauf, die Risiko einer Remote Code-Execution begrenzen. In den Vorankündigungen zu CVE-2022-3602 wurde dieses Problem als KRITISCH eingestuft. Weitere Analysen auf der Grundlage einiger der oben beschriebenen abschwächenden Faktoren haben dazu geführt, dass dieses Problem auf HOCH herabgestuft wurde. Den Benutzern wird weiterhin empfohlen so schnell wie möglich auf eine neue Version zu aktualisieren.
Anzeige
CVE-2022-3786: X.509 Email Address Variable Length Buffer Overflow
Bei der Überprüfung von X.509-Zertifikaten, insbesondere bei der Überprüfung von Namensbeschränkungen, kann es zu einem Pufferüberlauf kommen. Beachten Sie, dass dies nach der Zertifikatsketten-Signaturprüfung auftritt und erfordert, dass entweder eine CA ein bösartiges Zertifikat signiert hat oder dass eine Anwendung die Zertifikatsüberprüfung fortsetzt, obwohl kein Pfad zu einem vertrauenswürdigen
Emittenten existiert.
Ein Angreifer kann eine bösartige E-Mail-Adresse in ein Zertifikat einbauen, um eine beliebige Anzahl von Bytes, die das Zeichen `.' enthalten, auf dem Stack zu überschreiben. Dieser Pufferüberlauf könnte zu einem Absturz führen (was eine Dienstverweigerung zur Folge hat). In einem TLS-Client kann dies durch die Verbindung zu einem bösartigen Server ausgelöst werden. Bei einem TLS-Server kann dies ausgelöst werden, wenn der Server eine Client-Authentifizierung anfordert und ein bösartiger Client eine Verbindung herstellt. Die Schwachstelle wird mit dem Schweregrad Hoch bewertet und wurde am 18. Oktober durch Viktor Dukhovni gemeldet.
Es sind nur die OpenSSL-Versionen 3.0.0 bis 3.0.6 für beide Schwachstellen anfällig. Bisher ist kein funktionierender Exploit für die zwei CVEs bekannt, der zur Codeausführung oder Ausnutzung führen könnte. Benutzer von OpenSSL 3.0 sollten ein Upgrade auf OpenSSL 3.0.7 durchführen. OpenSSL 1.1.1 und 1.0.2 sind von diesen Schwachstellen nicht betroffen.
Damit erweist sich die Schwachstellenproblematik als nicht so kritisch wie ursprünglich befürchtet. Der aktualisierte Quellecode des Projekts findet sich dieser Projektseite. Es ist davon auszugehen, dass betroffene Linux-Distributionen und die Hersteller betroffener Software-Produkte bald entsprechende Sicherheitsupdates bereitstellen. Als Endanwender bleibt eh nur die Option, auf solche Updates der Softwarehersteller zu warten und diese dann zu installieren.
Ähnliche Artikel:
Hinweis: Patch für OpenSSL Schwachstelle zum 1. Nov. 2022
nginx for Windows von OpenSSL Privilegien-Schwachstelle betroffen
Anzeige
Ein Update wurde auch auf Linux Mint 21 ausgeliefert, nach der Installation ist die Version jedoch weiterhin 3.0.2
Möglicherweise wurde unter Mint der Patch auf v3.0.2 gebackportet.
Möglicherweise erhälst Du in den kommenden Tagen weitere Patches.
Linux: Bin ich gerade mit meiner Linux-Distri betroffen?
Hier hilft das NCSC-NL (Nationaal Cyber Security Centrum Niederlande) mit einer recht langen Liste von Appliances und OS'sen: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software
Linux @ Blupp @ Mint
Tip1: Prüfe Versionen – siehe Link oben, was sagen Paket-Descriptions im REPO? Kann mir fast nicht vorstellen (not blaming Mint – andere haben auch noch nichts im REPO) das Mint hier soo schnell ist :-) …
Tip2: ggf Terminalrestart und Ausgabe "openssl version" in Neuem (ENV,Vars)
Tip3: Wir sollten hier nicht allzusehr ins Detail gehen – sicher nicht die optimalste Form für den Blog
Linux: Und wenn ich unbedingt am Rechner etwas machen will oder muss?
Ubuntu ab Version 20.04. Jammy nutzt die anfällige Version 3., mit etwas Aufwand und Zeit lässt sich z.B. eine neue Version parallel zur normalen Distribution kompilieren und installieren. Auch für Systeme mit „alter Version" wie Debian 10 oder 11 und viele Appliances von Fileserver mit Openfiler bis Zentyal geht dies.
Je nach Fall macht das flexibler und ergänzt z.B die bei Debian 11 zwar sauber gepflegte aber doch schon einige Monate alte Version 1.1.1n durch die selbst Gewählte: Zusätzlich Schutz für SSL-Einwahl zu Servern oder die Niederlassung weil die einfache Appliance immer X Monate hinterher ist.
Hier ist man jedoch schnell in der Welt händischen Managements und der Compiler – und es soll auch „sicherer" und vernünftig sein. Ohne erste Erfahrung würde ich gerade bei SSL (auch openSSH mit Abhängigkeiten) von einem einfachen „make" oder „make install" abraten. Quellenverifizierung, Wahl der Compilerflags, Abhängigkeiten, Härtung – das erledigt sonst die tolle Community per REPO-Update.
Eine parallele Version stört die Distribution zB in „/usr/local/bin/openssl" nicht , Zertifikate lassen sich per Link je nach Ort verfügbar machen „ln -s /etc/ssl/certs/ certs", Ich nutze für CFLAGS oder CXXFLAGS mindestens -flto -Werror -Wformat=2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -z relro -z now" …
Vielleicht komplex im dauerhaften Management – jedoch: Früher Vogel fängt den IT-Sicherheitsvorfall-Wurm
Die Sicherheitsgefahr wird auf "hoch", nicht auf "kritisch" eingestuft.
Daher denke ich wenn man keinen wirklich guten Grund hat, sollte keine eigene Version Compilieren, sondern warten bis der Distributor die Sicherheitslücke offiziell fixt. Das wird in gängigen Distributoren in den nächsten Tagen erfolgen.
Auch für Ubuntu 22.04 GNOME gab es ein Update. Lasse ich jedoch nach einem Neustart die Version mit openssl version ausgeben:
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
Verwunderung, viel Erwartungshaltung, Versionschaos. Leider gibt es Lösungen nicht immer auf Knopfdruck zur Stich-Stunde. Hier nur zur Klarstellung:
Jede Distribution hat eigene Security Announces, eigene Repositories und idR individualisierte Versionierungssyntax/semantik. Diese sind erst einmal relativ unabhängig von dem, was openSSL heute veröffentlichte. Ebenso hat jede Installation eine zu pflegende oder während Install ausgewählte Quelle an Updates mit „Zweigen" oder Paketquellen (/etc/apt/sources.list, Paketverwaltung wie „Synaptic").
Pakete: kurz umrissen gibts verschiedene Möglichkeiten, eine Paket und somit eine Version zu installieren/aktualisieren. Beeinflusst durch die Zweige/Quellen: Über „Security-Updates, über „normalen Updates", über ganz normales Pakete. Beeinflusst durch Art der Aktualisierung des Pakets: Generiert die Distribution ein Paket mit einer neueren Hauptversion? Wie McAlex777 oben nennt: Ist es Backport vom Update? Anzeichen sind hier oft die Versionsnummern am Ende – bei Ubuntu oder Debian zB oder „u" mit .
Leider ist es nun des Technikers oder Nutzers Job, hier zu handeln – das lateinische „Administrator" kennen wir heute noch, nehmt den verbalisierten Imperativ: Verwaltet! Leitet!
Ubuntu – Security Announces: https://ubuntu.com/security/notices/USN-5710-1
Debian – Security Announces: https://lists.debian.org/debian-security-announce/
Auf den Mirrors – also in dortigen Repositories – liegen für unsere Installationen und Updates viele Pakete. Diese sind für das jeweilige OS-Release, die jeweilige Plattform und die gewählten Zweige/Paketquellen unterschiedlich. Um zu sagen was überhaupt los ist empfehle ich:
1. Check der Security-Announces – welche Version sollte oder darf ich bekommen?
2. Check der Sources.list oder GUI – welche Versionszweige kann ich überhaupt bekommen?
3. Check der Packages – welche Version habe ich denn bekommen? Gibt es die schon per Update?
3.1. Versionsprüfung des Pakets – passt dies zu 1) und Security Announces? Verifizierbar über GUI oder commandline, zB Debian: „apt show openssl"
4. Check der Software selbst – z.B. „openssl version", Output oft auch im Kontext der Distribution zu betrachten.
Eine aktualisierte oder gebackportete Version muss daher als Paket oder am Prompt nicht überall und keinesfalls exakt so heißen wie die Version die – hier von openSSL 3.07 oder 1.1.1n genannt – dahinter steckt. Nur ein Grund mag sein, dass die Distributionen hier für Euch kompilieren, entscheiden ob man backportet oder komplett updatet. Weiterhin gilt: Sicherheitsquellen müssen lokal aktiviert sein, die Mirror-Server der Distis (siehe Bsp-Links unten) müssen sich aktualisiert haben. Auch das kann je nach Disti und Security-Mirror-Strategie mal 3-24 Stunden dauern. Interessante Topologie übrigens – und am Rande zum Thema SSL passend: Die meisten von Euch werden sie Sicherheitsupdates wohl noch ohne https abrufen was erst einmal erträglich aber nicht für jeden Fall optimal ist.
Was bedeutet das nur beispielhaft für unser SSL wenn man RTFM spielt und nachschaut:
Ubuntu 22.10 – hat Announce draussen – geht auf Version „libssl3 – 3.0.5-2ubuntu2"
Ubuntu 22.04 – hat Announce draussen – geht auf Version „libssl3 – 3.0.2-0ubuntu1.7"
Debian 11 Bulls – security – amd – 64bit – packagename „openssl" – hat zum Stand des Schreibens noch kein Announce draussen, die Packagelist noch kein Paket, wird wohl auch etwas dauern, da 1.1.1n unter Bullseye nur teilweise betroffen ist: https://lists.debian.org/debian-security-announce/2022/threads.html , https://security.debian.org/debian-security/dists/bullseye-security/main/binary-amd64/Packages.xz , Damit verbleibt die Version 1.1.1n-0+deb11u3 (noch nicht voll gefixt – aber auch nicht so kritisch wie der 3er Branch)
22.04 wäre dann aber jammy -> bis 22.04 ist noch openssl 1.1.1 Default.
Hey, richtig – Danke für Feedback
Ubuntu – ja, Jammy in Verbindung mit 20.04 war falsch – ebenso gibts Typos, konnte gestern wg Fehler nicht mehr Editieren- kann grad nicht gerade tippen und hab gestern ebenso Hrn Borns bold-Formatierung zerhauen (Danke, Tramadol)
yes – 22.04 ist… Jammy , ein LTS
yes – Bis 21.10 Impish „default" listet man im main oder update noch 1.1.1 :
Compiling @ McAlex777 – dies würd ich auch nicht überall machen und dachte ich hätte es so grob angedeutet.
Es gibt viele Gründe warum zB im professionellen Bereich ein Admin gar nicht entscheiden sollte oder darf, ob „man das machen würde" – relevanter kann hier die Firmen-Vorgabe, Kundenwunsch, die Compliance, das Audit, Risikoniveau etc sein – solange er nicht entsprechende Rollen hat, bspw. „Der Boss" oder „Risiko-Owner". Das Sammeln von mittlerweile 13 Sicherheitslücken seit 1.1.1n bis inkl. 1.1.1s kann je nach Anwendungsfall fatal sein – nur weil die ja grad nur „hoch" sind ( https://www.openssl.org/news/cl111.txt ) Wenn man jedoch alle Lücken brav abgeprüft, gelesen und auf Impact geprüft hat – dann hätt ich auch nichts dagegen lange zu warten. Darin versteckt sich eine Message: Eigentlich müssten wir einzelner prüfen – und nicht auf CRITICAL warten.
Linux abschliessend – jeder kann oder sollte an o.g. Stellen schauen (Punkte 1.-4.), exemplarisch für Eure Distributionen. Ab und an ist die Vernummerung der Distributionen zum navigieren nicht ideal – aberschaffbar. Es gibt diverse schöne Übersichten – obigen Punkte 1-4 ergänzt zB https://packages.ubuntu.com/impish-updates/openssl .
Beispiel – 20.04 LTS Focal: Die Quellen liefern „default" Paket 1.1.1f-1ubuntu2.16, per Quelle „update" schon Paket 1.1.1f-1ubuntu2.16, keine weiteren Updates zu zum Schreibzeitpunkt gestern als Security Update schon „announced"
Warum sollte man m.E. der Distribution Sicherheitsupdates überlassen?
Weil vielleicht morgen das nächste Sicherheitsupdate kommt, was der Admin nicht mitbekommt. Blöd wenn man dann schon eigene Versionen verwendet.
Weil der Distributor in der Regel sehrviel besser Seiteneffekte abschätzen kann, welche Berücksichtigt werden wollen.
Weil der Distributor in der Regel sehrviel mehr Erfahrung mit dem Compilieren/Paketieren und möglicherweise speziellen Flags hat.
Es ist Aufgabe der Distribution für zeitnahe Sicherheitspatches zu sorgen.
Tut sie das nicht, hat man ein grundsätzliches Problem.
"Es sind nur die OpenSSL-Versionen 3.0.0 bis 3.0.6 für beide Schwachstellen anfällig. Bisher ist kein funktionierender Exploit für die zwei CVEs bekannt, der zur Codeausführung oder Ausnutzung führen könnte."
> Jein, also ein DoS mit CVE-2022-3602 unter Windows Umgebungen(32b,64,b) wäre mir bekannt, ist die Frage, ob man dies unter Ausnutzung zählt: https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/
P.S.: Da ich hier zum ersten Mal schreibe, danke für deine gewissenhafte und lesenswerte Arbeit!
@ McAlex777 – Du hast doch völlig recht, alle Punkte sind für sich erst mal schlagkräftig. Und privat, oder überschaubar, im unkritischen Bereich oder semiprofessionell sehe ich ebenso derzeit auch wenig Gründe & Probleme sofort Compilieren zu lernen statt 2 Tage zu warten und mal keine Schmuddelseiten zu surfen ;-p (meine hier die 1.1.1s-Version).
Punkt 1 von Dir: Es ist eine der Kernaufgaben einer Firma diese Möglichkeiten zu planen – ebenso Aufgabe des Admins es gefälligst zu schaffen ;) ein angemessenes Risikomanagement ist vorzuhalten. Wenn man jedoch von vornherein einplant das man vergisst ist hier der organisatorisch verantwortliche dennoch haftbar. er tut also gut daran, zwei von uns einzustellen. Du darfst mal vergessen, ich erinnere uns dann.
Punkt 2+3 sehr gute Punkte, gehe 99% d'accord – hatte mal umgeschulte Hotelier-Azubi-Administratoren in London unter mir, keine Vorurteile allgemein – jedoch das ein Graus.
Punkt 4 Hier würde ich differenzieren – dass das oben eher als Anreiz gedacht war ist sicher deutlich geworden ( "wer umbedingt will", "abraten", "Möglichkeit",…)
In Anderen Bereichen – egal ob im Rechenzentrumsbereich oder in einer Firma nutzt man jedoch Vieles – von Solaris-Miet-Cluster bis zum Debian LTS, am besten noch kreuz und quer verdrahtet mit IPC-Prozesskommunikation per SSL. Auch Betreuer X von hunderten Großkalibersportschützen mit Vereinsdatenbank, Waffentypen und Adressen auf dem toll gemieteten selbst gemanagten Rootserver kenn ich.
Wenn es "größer" und "sensibler" wird macht es einen Unterschied ob man + wie man patcht, schneller oder langsamer, vollständig oder nur ab "critical". Jede Stunde zählt. Stell Dir eine "alte" SSL bei gern genutzer Debi Bullseye LTS mit ca 13 mittleren Lücken von denen 1-3 kombiniert werden könnten an 50 Kundenservern vor: Alle generieren 100-300 € pro Monat/Miete und machen pro Tag im Schnitt 10000€ Umsatz. Administration macht Dein Team, Die Server stehen unter Audit – mal egal was, PCI DSS, ISEA… und Du bist verantwortlich. Spätestens da hat man ein reelles Szenario: 10K€ Umsatz für Dich pro Monat, für alle Nutzer 500K€/Tag, pro Minute 347€.
dies ist keine Kritik an McAlex777 und auch nicht persönlich
Setzt Du Dich hin und findest für die Disti und Software eine Fallback-Lösung? Hast Du gefälligst einen Notfallplan bereit, der Dir eine Alternative in 30 Minuten SLA-Zeit biete? Warum nicht? Rechnet sich ein Fachmann wie Wir eine Woche im Monat, um jede Dependency zu checken und für die Hälfte Systeme automatisiert per Script zu compilen?
Oder bist Du, sind wir Risikoaffin? Schau dich hier im Blog mal um – und zähl die gecrashten Unternehmen in den letzten 2-5 Jahren :-) (Ach ja, Danke an Borncity – ich mach das wirlklich ab und an, hab nen Born-Heise-"Fan"-IT-Zwischenfall-Ordner)
Worauf läufts hinaus? Bei steigender Komplexität resultiert aus dem "Restrisiko von nur 5 oder 2%" ein Hebel der dennoch riesig ist.
Generell ist das "kann doch machen – sei nicht übertrieben" übrigens ein total menschlich-psychologisches Verhalten bei abstraktem Risiko oder auch hohem Ertrag mit geringer Eintrittswahrscheinlichkeit – jedoch nicht immer logisch und gut !;-)
Es geht mir um Abwägen, um Vernunft. Pauschalisierend die "im Normalen" oder Hausgebrauch geprägte Sichtweise in größeren Dimensionen anzuwenden – so wie es selbst jede 2. Behörde scheinbar in den letzten Jahren bei IT bis zu einer Lauterbach-gelobten App tut… Ohhauerha wüsst ich Sachen… dann wird aus Spass Ernst – und Ernst ist mir in den letzten Jahren nicht nur schon viel zu Alt – sondern hat auch schon zu viele Brüder.
Wir spielen Lotto – obwohl das nu mal gar nicht statistisch logisch ist – es ist systemkritisch und schädlich für uns Alle wenn das allgemein so weiter geht in der IT . Ebenso gehen wir Risiken ein und blenden oder Leugnen die letzten 1,734599 % Restrisiko einefach weg, schlechtes gutes Beispiel: Guck Dir unsere "Risikomanager der Regierung" an – *seufz*
Ach ja – das Hamsterrand geht weiter: @ Günter Born wo bleibt der Openvpn-Artikel? Deine Jünger brauche Futter:
https://openvpn.net/community-downloads/
Ich jedenfalls gehe meine Drogen nehmen und kippe wieder um. So viel zum Thema ungeplante Risiken.