[English]Zum 11. Januar 2022 hat Microsoft die Schwachstelle CVE-2021-22947 in Windows 10, Windows 11 und in deren Server Pendants mit diversen Sicherheitsupdates geschlossen. Die Schwachstelle CVE-2021-22947 betrifft die cURL-Bibliothek und wurde vom deutschen Sicherheitsforscher Stefan Kanthak bereits im Sommer 2021 an Microsoft gemeldet. Mir liegt die zähe Korrespondenz zwischen Kanthak und dem MSRC vor, und es ist auch erkennbar, dass Microsoft cURL mehr schlecht als recht pflegt, so dass ich diesen Fall hier mal im Blog aufbereite.
Anzeige
Darum geht es bei cURL
Microsoft liefert seit Anfang 2018 mit Windows 10 das Paket cURL mit. Das ist einerseits eine Programmbibliothek und gleichzeitig ein Kommandozeilen-Programm zum Übertragen von Dateien in Rechnernetzen. cURL steht unter der offenen MIT-Lizenz und wurde auf verschiedene Betriebssysteme portiert.
Bei Microsoft gibt es aber das Problem, dass die zwar vollmundig herumposaunen, cURL mit Windows 10 (und aktuell Windows 11) auszuliefern. Aber die Pflege des cURL-Pakets, speziell im Hinblick auf das Schließen bekannter Schwachstellen, ist Microsoft-like. Da wird das Paket schon mal zwei Jahre nicht gepatcht, und eine als kritisch eingestufte Remote Code Execution-Schwachstelle in cURL braucht über ein halbes Jahr – und 3 Monate nach deren Offenlegung – bis diese gepatcht wird. Und der Janauar 2022-Patch kann wegen Kollateralschäden ggf. nicht installiert werden.
cURL-Schwachstelle: Erste Bestätigung Microsofts
Im cURL-Paket gibt es die Schwachstelle CVE-2021-22945. Wenn curl >= 7.20.0 und <= 7.78.0 eine Verbindung zu einem IMAP- oder POP3-Server herstellt, um Daten mit STARTTLS abzurufen und auf TLS-Sicherheit umzustellen, kann der Server antworten und mehrere Antworten auf einmal zurücksenden, die curl im Cache speichert. curl stellt dann auf TLS um, leert aber nicht die Warteschlange der im Cache gespeicherten Antworten, sondern verwendet weiterhin die Antworten, die es *vor* dem TLS-Handshake erhalten hat, als ob sie authentifiziert wären, und vertraut ihnen.
Durch diese Schwachstelle kann ein Man-In-The-Middle-Angreifer zuerst die gefälschten Antworten einschleusen, dann den TLS-Verkehr des legitimen Servers durchschleusen und curl so austricksen, dass es Daten an den Benutzer zurücksendet, in der Annahme, dass die vom Angreifer eingeschleusten Daten vom TLS-geschützten Server stammen.
Anzeige
Die Schwachstelle wurde von Stefan Kanthak entdeckt und an Microsoft gemeldet. Die initiale Nachricht von Kanthak an das Microsoft Security Response Center (MSRC) habe ich nicht zur Verfügung, da Stefan Kanthak mir nur einen Auszug der Korrespondenz zur Verfügung gestellt hat. Am Montag, den 26. Juli 2021 bestätigt das MSRC das gemeldete Problem in Curl:
From: Microsoft Security Response Center
Received: Mon Jul 26 2021 08:05:07 GMT-0700 (Pacific Daylight Time)
To: Stefan Kanthak
Subject: MSRC Case 66388 CRM:0461283373Hi Stefan,
Here's an update on your case:
MSRC Case 66388
We confirmed the behavior you reported. We'll continue our investigation and determine how to address this issue.
Please let me know if you have additional information that could aid our investigation, or if you have questions.
Thanks!
Duncan
MSRC
An dieser Stelle hätte man der Vorstellung nachhängen können, dass die Schwachstellen bis zum kommenden Patchday geschlossen wird.
Im Oktober 2021 zugesagte Korrektur nicht erfolgt
Nachdem dieser Case irgendwie im Sande zu verlaufen schien (kein Fix im Oktober 2021; gemäß nachfolgendem Text war von Microsoft aber ein Patch für Oktober 2021 zugesagt), hat Stefan Kanthak zum 12. Oktober 2021 nochmals nachgehakt:
From: Stefan Kanthak
Received: Tue Oct 12 2021 15:45:15 GMT-0700 (Pacific Daylight Time)
To: <Microsoft Security Response Center>; Microsoft Security Response Center; Microsoft Security Response Center
Subject: Re: MSRC Case 66388 CRM:0461283373Duncan <secure@microsoft.com> wrote Thursday, August 05, 2021 2:09 AM:
> Hello Stefan,
>
> Thank you for working with the MSRC!
>
> The fix is in development for your report, and is scheduled to be
> released in the October Microsoft Security Release on October 12th.WTF happened?
1. Neither Link nor KB5006670 nor KB5006672 list an update for curl.exe
2. Link KB5006672 doesn't list curl.exe!
3. 5006672.csv but lists the VULNERABLE and OUTDATED curl.exe 7.55.1, built more than 2 years ago:
| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
| curl.exe,7.55.1.0,12-Aug-2019,20:28,"421,376"
| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
…
| Windows 10 version 1809 LCU Arm64-based,,,,
| File name,File version,Date,Time,File size
| curl.exe,7.55.1.0,12-Aug-2019,19:37,"330,240"
…
| curl.exe,7.55.1.0,12-Aug-2019,19:46,"386,048"
…
| curl.exe,7.55.1.0,12-Aug-2019,20:22,"435,712"You had more than TWO FULL MONTHS to build curl.exe from its CURRENT sources, but FAILED MISERABLY to do so!
What happened to Bill Gates' "trustworthy computing"?
IT'S A REAL SHAME!> Will that date work for you for a disclosure date?
NOT ANY MORE!
> Thank you again for working with us,
not amused
Stefan Kanthak
Muss man sich auf der Zunge zergehen lassen: Im Oktober 2021 wird in Windows 10 und Windows 11 (sowie in den Server-Pendants) eine curl-Version 7.55.1.0 vom 14. August 2017 mitgeliefert (2019 von Microsoft compiliert). In dieser Uralt-Version sind zahlreiche Schwachstellen bekannt. Die Antwort von Microsoft (MSRC) auf die Anfrage von Kanthak kam am 12. Oktober 2021 und bestätigte, dass die curl-Schwachstelle nicht gefixt wurde.
Received: Tue Oct 12 2021 16:27:50 GMT-0700 (Pacific Daylight Time)To: <Microsoft Security Response Center>; Microsoft Security Response Center; Microsoft Security Response Center; Stefan KanthakSubject: Re: MSRC Case 66388 CRM:0461283373Hello Stefan,
Thank you for checking back on the status of your submission. You are correct that the update for Curl was not included in this
month's security update release. We are checking on the status of your case and will respond once we have an understanding of the
engineering groups' plans.Our apologies for the confusion.
Thank you for working with MSRC.
Duncan
MSRC
Stefan Kanthak hat dann den Fall auf seclist.org veröffentlicht und schreibt dort folgendes:
In December 2017, Microsoft announced to ship curl.exe and tar.exe
with Windows 10:
<Team Blog:Tar and curl come to Windows>But they failed once again, MISERABLY, at least for curl: they took
the sources released 2017-11-14, let them rot for 2 years, applied
some patches, only to let them rot again since then!| C:\Users\Public>winver
| Microsoft Windows [Version 10.0.19042.1083]
|
| C:\Users\Public>curl -V
| curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
| Release-Date: 2017-11-14, security patched: 2019-11-05
| Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
| Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSLVersion 7.55.1 is 34 releases and at least 15 (in words: FIFTEEN)
CVEs behind the current version 7.79.1: see
<https://curl.se/docs/releases.html> and
<https://curl.se/docs/vulnerabilities.html>Most obviously Microsoft's processes are so bad that they can't
build a current version and have to ship ROTTEN software instead!stay tuned, and far away from such poorly maintained crap
Microsoft liefert also curl.exe seit Anfang 2018 mit Windows 10 mit (dem damals sichersten Windows aller Zeiten, laut Hersteller). Allerdings lässt Microsoft die alte Version von curl.exe zwei Jahre lang regelrecht verrotten, ohne sich um Patches zu kümmern. Erst Ende 2019 werden einige Patches in eine curl-Version übernommen. Dann gibt es wiederum zwei Jahre nichts an Änderungen, und es werden auch keine Sicherheitsupdates vorgenommen.
Zum Zeitpunkt der Meldung der obigen Schwachstelle durch Stefan Kanthak waren mindestens 20 Sicherheitslücken in curl bekannt und in der Open Source-Variante geschlossen. Nur Microsoft lässt das kalt, im "sichersten Windows aller Zeiten" (O-Ton Microsoft) werden uralte Bibliotheken mit bekannten Sicherheitslücke ausgerollt und es kratzt keinen. Da bleibt der Beobachter sprachlos zurück – obwohl: Das ist bei Microsoft Programm – ich kenne andere Fälle, wo Bibliotheken in uralten Versionsständen und mit bekannten Schwachstellen in Produkte integriert und fleißig verteilt wurden.
Weihnachten tut sich was …
Am 24. Dezember 2021 kam dann folgende Antwort von Microsoft an Stefan Kanthak – da hat offenbar jemand seinen Schreibtisch aufgeräumt:
From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "Microsoft Security Response Center" <secure@microsoft.com>; "Microsoft Security Response Center" <secure@microsoft.com>;
"Microsoft Security Response Center" <secure@microsoft.com>; "Microsoft Security Response Center" <secure@microsoft.com>; "Stefan Kanthak" <stefan.kanthak@nexgo.de>
Sent: Friday, December 24, 2021 12:05 AM
Subject: RE: Re: MSRC Case 66388 CRM:0461283373Hello Stefan,
The fix in development for your report has completed testing and is tentatively scheduled to be released in the upcoming Microsoft Security Release on January11th 2022. We will be referencing some of the CVEs that CURL has issued for recent updates, including CVE-2022-22947. While unlikely this is still subject to change, and I will be sure to notify you of any updates.
Thank you again for working with us,
Duncan
MSRCFrom: Microsoft Security Response Center
Dort wurde der Fix für den 11. Januar 2022 versprochen.
… aber es wird Januar 2022
In der Tat kam dann zum 11. Januar 2022 (Patchday) wirklich ein Update und die als kritisch eingestufte Remote Code Execution-Schwachstelle CVE-2021-22947 in Curl wurde in Windows 10 20H2 -21H2, Windows Server 2022 und in Windows 11 geschlossen. Die CVE war über Hacker One beantragt worden, eine Beschreibung von CVE-2021-22947 findet sich hier und hier. Inzwischen weist Microsoft Stefan Kanthak als Entdecker der Schwachstelle aus – was wohl erst auf erneutes Nachhaken passierte. Denn Kanthak schrieb in einer Mail "Fuer eine Danksagung langt's bei der Redmonder Klitsche auch nicht".
Eine Klitsche Namens Microsoft
Sind wir uns einig, dass Microsoft sich gerne als Nabel der Welt geriert? Und sind wir uns einig, dass das Credo Microsofts und der Zunft der Sicherheitsfirmen samt Experten "immer patchen, damit die Systeme aktuell sind, und immer die neueste Softwareversion einsetzen" lautet? Momentan geht mir der defätistische Gedanke "Brot und Spiele fürs Volk" durch den Kopf. Warum?
Vor einigen Tagen hatte ich im Blog-Beitrag Eset und die Meldung von 3 Millionen unsicheren deutschen Windows-Computern die neueste Sau, die in den Mainstream-Medien in Punkto Sicherheit, durchs Dorf getrieben wurde zerpflückt. Und nun kommt mit obiger Fall wie gerufen, um weiter Salz in die Wunden zu streuen.
Microsoft bläst mächtig in die Backen, wenn es darum geht, wie toll man ist und was alles an Open Source-Funktionen, von WSL bis cURL in Windows 10/11 integriert wird. Aber mir bleibt die Spucke weg, wenn ich oben lese, wie lausig dieses Zeugs gepflegt und mit Sicherheitspatches versorgt wird.
Es ist schon sportlich, wenn eine als kritisch eingestufte RCE-Schwachstelle in einer curl-Bibliothek erst nach einem halben Jahr (und 3 Monate nach Offenlegung) gefixt wird. Von den Zwei-Jahres-Pausen bezüglich cURL-Updates erst gar nicht zu reden. An dieser Stelle sollten bei jedem Beobachter die Glocken klingeln, wenn Microsofts Marketing-Leute oder Sicherheitsfirmen und Sicherheitsexperten herauströten, wie wichtig aktuelle Betriebssystem und Updates sind. Klar, Updates sind wichtig, wenn, ja wenn auch die bekannten bzw. gemeldeten Schwachstellen beseitigt werden. Das ist aber wohl im Microsoft-Kosmos nicht wirklich der Fall – und ich denke, bei anderen Firmen auch nicht.
Ähnliche Artikel:
Eset und die Meldung von 3 Millionen unsicheren deutschen Windows-Computern
Datenleck bei deutschen Shopping-Plattformen (700.000 Kundendaten online)
Microsoft Teams und die Sicherheit …
Teams: Erfolgreich, aber ein Sicherheits-GAU
Microsoft Teams Bugs: Notrufe blockiert, Phishing-Lücke seit März 2021
Auf dem Electron-Framework basierende Apps angreifbar
Edge: Hat Microsoft den Kompass verloren?
Bug in Origin von Electronic Arts gefährdete Windows-Nutzer
Microsoft, die Nachhaltigkeit und Windows 11 als Umweltkatastrophe – Teil 1
Edge: Installer-Sicherheit mangelhaft
Microsoft will Installer-Schwachstelle nicht schließen
Sicherheit: Microsoft Visual C++ Runtime kommt mit alten Wix-Installern und Schwachstellen
Microsoft und die Office 20xx-Sicherheitslücke in ose.exe
Windows 10 und die OneDrive-Sicherheitslücken – Teil 1
Windows 10 und die OneDrive-Sicherheitslücken – Teil 2
Windows 10 und die OneDrive-Sicherheitslücken – Teil 3
Ähnliche Artikel zu Jan 2022 Patchday-Problemen:
Windows Server: Notfall-Update fixt Remote Desktop-Probleme (4.1.2022)
Windows Server: Januar 2022-Sicherheitsupdates verursachen Boot-Schleife
Windows VPN-Verbindungen (L2TP over IPSEC) nach Januar 2022-Update kaputt
Windows Server 2012/R2: Januar 2022 Update KB5009586 brickt Hyper-V Host
Microsoft Januar 2022 Patchday-Revisionen (14.1.2022)
Microsoft Patchday-Probleme Jan. 2022: Bugs bestätigt, Updates zurückgezogen?
Sonderupdates für Windows mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 11/Server 2022 Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 10/Server: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Windows 7/8.1; Server 2008R2/2012R2: Sonderupdates mit Fixes für Jan. 2022-Patchday-Probleme (17.1.2022)
Sonderupdate für Windows Server 2019 fixt Jan. 2022-Patchday-Probleme (18.1.2022)
Nachlese: Fix für Windows IPSec VPN-Verbindungproblem
Sonderupdate für Windows (17./18. Jan. 2022) fixen ReFS-Probleme nur teilweise
Access-Lock-Bug durch Microsoft Office Updates (11. Januar 2022)
Anzeige
Irgendeine Hackergruppe wird es schaffen, etwas zu entwickeln, was Windows, ob 10 oder 11 egal, komplett lahm legen wird. Dann wird das Geschrei groß sein, weil, es kam ja so überraschend… Kann mich ja täuschen aber langsam lädt MS ja richtig zu diesem "sportlichen Wettbewerb" ein.
Ist schon traurig, daß jede Hobbydistribution das besser kann. Ist auch überhaupt nicht nachvollziehbar, warum man manuell für eine alte Version Sicherheitsfixes zurückportiert statt einfach die aktuelle Version zu nehmen.
Natürlich machen Red Hat und andere das in ihren Langzeitprodukten auch so, aber das ist enormer Aufwand, der viel Koordination und Knowhow braucht und Arbeit macht. Sowas macht man nicht mal eben nebenbei.
Keine Korrektur für deinen Artikel: curl 7.55.1 ist ein Release von 2017. 2019 ist das Jahr, in das Microsoft die damals schon zwei Jahre alte Version kompiliert hat.
https://github.com/curl/curl/releases/tag/curl-7_55_1
Habe es korrigiert, danke.
Wir benutzen Curl z.B. um Imap-Postfächer zu lesen usw.
Bestimmte Dinge (das Verschieben von Emails) klappte mit der mitgelieferten Version nicht. Auf der Curl-Webseite haben wir uns dann die aktuelle Version geholt. Das machen wir jetzt immer. So ist es uns egal, ob jemand etwas mitliefert oder nicht.
Im Installationsverzeichnis von Exchange Server 2016 liegen auch uralte Binaries welche zu "Oracle Outside In Technology" gehören. Diese weisen bekannte Sicherheitslücken auf und wurden nie durch ein CU oder SU aktualisiert. Ich kann allerdings nicht beurteilen ob davon ein ausnutzbares Risiko ausgeht. Passt aber irgendwie zum veralteten cURL.
Mein Stil wäre das nicht, wie S.Kanthak da am Tue Oct 12 2021 15:45:15 mit MS kommuniziert, auch wenn die Kritik berechtigt ist. Heute macht man das doch so, dass man mit Anstand 90 Tage nach Meldung eines Problems einen funktionierenden Proof of Concept Angriff auf Github oder so veröffentlicht. Und ohne Anstand direkt nach Entdeckung. Gibt auch so schöne Webseiten wie kitploit wo man sich über solche Sachen freut. Nunja, als ich von Problemen mit curl.exe in Windows gelesen hatte, hab ein bischen damit rumgespielt, festgestellt dass man damit Sachen machen kann, die ich in unserer Domäne nicht haben will, und habe es per Applocker gesperrt, fertig.