[English]Es ist eine unschöne Geschichte, die ich erneut hier im Blog einstelle. Microsoft gelingt es nicht, cURL mit Windows so auszuliefern, dass die Software auf dem aktuellen Stand ist und keine bekannte Sicherheitslücken mehr aufweist. Ich hatte das Thema bereits im Januar 2022 im Blog aufgegriffen – geändert hat sich aber nichts, wie ich aus einer Nachricht von Stefan Kanthak entnehmen konnte. Hier ein kurzer Abriss, um was es geht.
Anzeige
Was ist cURL?
cURL (steht für Client for URLs oder Curl URL Request Library) 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.
cURL in Windows 10/11 veraltet
Microsoft liefert cURL seit 2017 mit Windows 10 (und auch in Windows 11) mit, wie man in diesen Artikel auf der cURL-Webseite, sowie dem Blog-Beitrag Tar and Curl Come to Windows von Microsoft, der letztmalig am 26. April 2022 aktualisiert wurde, lesen kann. Ich hatte es im Dezember 2017 im Blog-Beitrag Windows 10: tar und curl sollen kommen angesprochen. Auf der cURL-Webseite heißt es dazu:
All installs of Microsoft Windows 10 and Windows 11 get curl installed by default since then. The initial curl version Microsoft shipped was 7.55.1 but it was upgraded to 7.79.1 in January 2022.
The Microsoft provided version is built to use the Schannel TLS backend. […]
The curl tool shipped with Windows is built by and handled by Microsoft. It is a separate build that will have different features and capabilities enabled and disabled compared to the Windows builds offered by the curl project. They do however build curl from the same source code. If you have problems with their curl version, report that to them.
You can probably assume that the curl packages from Microsoft will always lag behind the versions provided by the curl project itself.
cURL for Windows ist laut der cURL-Webseite am 20. Februar 2023 auf die Version 7.88.1 worden. Frage ich die cURL-Version unter einem Windows 10 mit aktuellem Patchstand ab, erhalte ich diese Anzeige:
Anzeige
In Windows 10 22H2 mit Patchstand Februar 2023 wird ein cURL 7.83.1 mit einem Release-Datum 13. Mai 2022 gemeldet. Die hängen 9 Monate hinter dem offiziellen Release des cURL-Projekts hinterher. Befrage ich das Internet nach "cURL 7.83.1 vulnerabilities", liefert mir Google den Link auf die offizielle cURL-Seite, wo es heißt:
curl version 7.83.1 was released on May 11 2022. The following 13 security problems are known to exist in this version.
Macht irgendwie schon Laune, zu erfahren, wie Microsoft so agiert. Oben hui, unten pfui, weiß der Volksmund – die nehmen auf ihren Webseiten das Maul mit zig Sicherheitsfeatures (Secure Boot, TPM, Exploit Schutz, Phishing Schutz etc.) voll, rotzen aber hinten rum Uralt-Bibliotheken mit bekannten Sicherheitslücken auf die Systeme der Anwender. Bei Produkten mit dem Electron-Framework wie Teams ist das genau so – da wurde auch fleißig eine uralte Version des Chromium Browsers mit bekannten Schwachstellen ausgeliefert.
Ergänzung: Curl soll sich laut einem Kommentar auf Facebook mit folgendem Befehl aktualisieren lassen: winget install curl.curl
Microsoft weiß das
Man könnte noch argumentieren, dass da "mal was übersehen" wurde. Aber das Ganze hat Methode, die Entwickler in Redmond wissen das und tun nichts. Im Januar 2022 hatte ich, nach einem Hinweis von Stefan Kanthak schon mal dieses Thema im Blog-Beitrag Windows Januar 2022-Sicherheitsupdates für cURL-Schwachstelle CVE-2021-22947 – ein zähes Unterfangen angesprochen. Kanthak hatte mir die Kommunikation mit Microsoft zur Verfügung gestellt, in der er auf Sicherheitslücken in cURL hinwies.
Die Tage hat Stefan Kanthak mir erneut eine E-Mail zukommen lassen, die obige Schlamperei bezüglich der Aktualisierung von cURL in Windows 10 und Windows 11 aufgreift. Hier der Text, ohne weitere Kommentierung meinerseits:
Hallo Guenter, beim CC: habe ich dummerweise (D)eine falsche Mail-Adresse angegeben. Magst Du ueber deren fortlaufende Schlamperei und Unfaehigkeit, die eigenen Produktionssysteme mit aktuellen Quelltexten zu bestuecken, schreiben? mfg Stefan ----- Original Message ----- From: "Stefan Kanthak" <****> To: "Microsoft Security Response Center" <secure@microsoft.com>; <certbund@bsi.bund.de>; <cert@cert.org> Cc: <gborn@***>; <daniel@****> Sent: Monday, February 06, 2023 7:56 PM Subject: TEN unfixed CVEs in the OUTDATED version of curl.exe that Microsoft dares to ship with Windows! > Hi @ll, > > Microsoft again/still ships a ROTTEN and VULNERABLE version of curl.exe > which is 4 releases behind and has TEN unfixed CVEs with Windows 10 and 11! > > Why do you ignore your own mantra "Keep your systems up-to-date and patched"? > > @MSRC: last time it took more than FIVE months, from 2021-07-21 until > January 2022, to ship a version then "just" 2 releases behind. > See MSRC Case 66388 CRM:0461283373 > > @CERT Bund: wie waer's mit einer oeffentlichen Warnung vor diesem > schlampig, fahr- und nachlaessig zusammengefrickelten Kram? > > @Daniel: please change your license to forbid the distribution of vulnerable > binaries built from outdated sources! > > C:\Users\Stefan>ver > > Microsoft Windows [Version 10.0.19044.2486] > > C:\Users\Stefan>curl --version > curl 7.83.1 (Windows) libcurl/7.83.1 Schannel > Release-Date: 2022-05-13 > Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp > Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets > > From <https://curl.se/docs/security.html> > > # S Vulnerability Date First Last > 132 ? CVE-2022-43552: HTTP Proxy deny use-after-free 2022-12-21 7.16.0 7.86.0 > 131 ? CVE-2022-43551: Another HSTS bypass via IDN 2022-12-21 7.77.0 7.86.0 > 130 ? CVE-2022-42916: HSTS bypass via IDN 2022-10-26 7.77.0 7.85.0 > 129 ? CVE-2022-42915: HTTP proxy double-free 2022-10-26 7.77.0 7.85.0 > 128 ? CVE-2022-35260: .netrc parser out-of-bounds access 2022-10-26 7.84.0 7.85.0 > 127 ? CVE-2022-32221: POST following PUT confusion 2022-10-26 7.7 7.85.0 > 126 ? CVE-2022-35252: control code in cookie denial of service 2022-08-31 4.9 7.84.0 > 125 ? CVE-2022-32208: FTP-KRB bad message verification 2022-06-27 7.16.4 7.83.1 > 124 ? CVE-2022-32207: Unpreserved file permissions 2022-06-27 7.69.0 7.83.1 > 123 ? CVE-2022-32206: HTTP compression denial of service 2022-06-27 7.57.0 7.83.1 > 122 ? CVE-2022-32205: Set-Cookie denial of service 2022-06-27 7.71.0 7.83.1 > > NOT AMUSED > Stefan Kanthak > > ----- Original Message ----- > From: "Stefan Kanthak" <stefan.kanthak@***> > To: "Microsoft Security Response Center" <secure@microsoft.com> > Cc: <daniel@***>; <cert@cert.org> > Sent: Wednesday, July 21, 2021 8:35 PM > Subject: OUTDATED curl.exe 7.55.1 > >> Hi secure, >> >> Windows 10 20H1, 20H2 and 21H1 ship with an outdated and vulnerable >> curl.exe 7.55.1, 32 releases and at least 15 (in words: FIFTEEN) CVEs >> behind the current version 7.78.0: see >> <https://curl.se/docs/releases.html> and >> <https://curl.se/docs/vulnerabilities.html> >> >> | 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 SSL >> >> Are your processes so bad that you can't build a current version and >> have to ship ROTTEN software instead? >> >> NOT amused >> Stefan Kanthak
Ähnliche Artikel:
Windows Januar 2022-Sicherheitsupdates für cURL-Schwachstelle CVE-2021-22947 – ein zähes Unterfangen
Microsoft Teams und die Sicherheit …
Anzeige
In der Sache sicher richtig, aber der Ton macht wahrscheinlich die Musik, wenn ich mir die Mails so ansehe. Wie wäre es statt dessen mit einem netten Proof of Concept, die CVEs sind ja hinlänglich bekannt und dokumentiert, und das dann bei bleepingcomputers oder kitploit als Hackingtool platziert oder in metaspoit integriert und dann wird was passieren.
ps. Ich habe curl.exe schon aufgrund des Artikels vor 1 Jahr per Applocker und Win-FW blockiert.
Vieles hat ja eine Vorgeschichte – Kanthak schickt Microsoft regelmäßig Hinweise auf Schwachstellen. In initalen Mails kommt meiner Beobachtung nach durchaus "das und das wurde gefunden" rüber. Wenn aber Schwachstellen angesprochen werden, wo offensichtlich ist, dass Microsofts Entwickler sich einen feuchten Kehrricht darum scheren, was deren Vorgänger 10 Jahre vorher als essentiell für einen guten und sicheren Programmierstil vorsetzen und auch publiziert haben, muss schon die Frage erlaubt sein, was in diesem Laden los ist. Und der Ton kann auch schon mal etwas forscher sein.
Wenn dann auch noch eine blasierte Antwort aus Redmond kommt – es sei alles nicht so schlimm und der Case wird geschlossen, sehe ich keine Veranlassung, da ein Proof of Concept zu entwicklen und mit "freundlichen Grüßen" an Microsoft zu schicken. Wir haben es ja mehrfach an Exchange gesehen, wie Microsofts Sicherheitsteam agierte – erst nix tun, dann an fünf Tagen sechs Revisionen zu Workaround rauschieben müssen, weil man sich mit dem Thema erst dann befasst hat, als es brannte.
Auch freundlich formuliert wird so etwas an Microoft abprallen. Mal drastisch ausgedrückt: Man muss Microsoft nicht in den Allerwertesten kriechen, bis man von innen aus den Augen heraus die Sicht aus Redmond wahrnehmen kann, in der Hoffnung, dass da neue Erkenntnisse bei herumkommen. Ich erlebe es ja auch, wenn ich Bugs an Microsoft melde.
PS: Finde ich gut, curl.exe zu blockieren.
Kann man also curl.exe bedenkenlos abschalten? Wird diese Datei standardmässig nicht gebraucht?
Wir brauchten in unserer Software die curl.exe zum Datenaustausch mit einem Fremdsystem. Darum wurde die Installationsanweisung um den Eintrag ergänzt, sofort die aktuelle curl-Version zu installieren. Zusätzlich wurde bei jedem Start die Version geprüft.
(Das Thema hat immer wieder zu "Kämpfen" mit Admins geführt.)
Magst Du mir ggf. noch ein paar Insights per Mail mitteilen? So einfach manuell cURL drüber installieren dürfte ja wohl nicht klappen – oder? Ich mache ggf. einen kleinen Beitrag drüber. Auf Facebook ist das Thema auch schon über mir zusammen geschlagen "was machen wir, wenn wir curl.exe brauchen …?"
Ist schon etwa 2 Jahre her.
Das Wort "Installation" ist bei curl wohl falsch. Man legt die neue Version in ein neues Verzeichnis. Dann passt man den Aufruf an (oder passt die Umgebungsvariablen an).
Auf der einen Seite sind Leue froh, dass Microsoft Tools einbindet, die man sich sonst eh manuell installiert hat und dann war man aber selbst für Updates verantwortlich. CURL ist aber keine Server Applikation sondern eine Kommandozeile, die jemand aufrufen muss. Als "angreifbar" wäre das System wohl nur, wenn jemand auf dem mit einem Skript/Programme wissentlich/unwissentlich eine URL anspricht, die die Lücke ausnutzt die dann im Prozess des Users aktiv wäre.
Dann müsste ich auch http://FTP.EXE, Invoke-Webrequest, Install-Module, Winget, NuGet, IE-ComAPI und andere Befehle zum Download von Code aus dem Internet verdammen. CURL wäre da mein kleinstes Problem.
Klar stände es Microsoft gut zu Gesicht, mitgelieferte Komponenten dann auch aktuell zu halten. Ich würde eher mich beschweren, dass eine Software mitkommt, die vermutlich nur wenige Dienste und Programme nutzen. Wer CURL braucht, kann es mit WINGET ja selbst installieren. Auf eigene Verantwortung.
Insofern ja, unschön aber meiner Meinung nach keinen Aufstand wert. Da gibt es andere Dinge, um die man sich kümmern sollte, d.h. all die Systeme, für die es gar keine Security Updates mehr gibt.
Habe aufgrund der RC4/AES-Thematik die letzten drei Monate viel mit Erstkunden zu tun gehabt, die immer noch "Altsysteme" haben. Und das sind "übe das Netzwerk" erreichbare Systeme und nicht eine kleine EXE, die ohne fremde Hilfe gar nicht erst aktiv wird.
Siehe https://www.msxfaq.de/windows/sicherheit/alte_clients.htm
AUTSCH: erst Denken, dann Schreiben.
M$FT predigt seit JAHREN allen Nutzern mindestens einmal pro Monat "Keep your systems up-to-date". Und was machen diese falschen Fuffziger selbst, auf ihren eigenen Systemen? NICHTS, sie lassen sie vergammeln und bauen aus veraltetem Zeux angreifbare Produkte mit denen sie ihre Nutzer beliefern. Nicht nur cURL!
DAS IST DER ERSTE PUNKT!
Der zweite Punkt: M$FT sind Wiederholungstäter, sie machen solche Fehler WIEDER und IMMER WIEDER, auch nach dem x-ten Hinweis, und das nicht nur bei cURL.
In meinen Projekten liefere ich nur noch eigene curl Versionen aus, die von MS sind nicht nur veraltet sondern auch noch zu stark unbrauchbar eingeschränkt…zumindest für meine Zwecke.
"Ergänzung: Curl soll sich laut einem Kommentar auf Facebook mit folgendem Befehl aktualisieren lassen: winget install curl.curl"
Ich habe den Befehl ausgeführt. Die Version und das Release-Datum haben sich danach aber gemäss Abfrage mit curl -V nicht geändert. (Vielleicht braucht es einen Neustart des PC. Den mache ich am Abend.)
Hallo zusammen,
anscheinend patcht Microsoft auch bei seinem OpenSSH-Feature in der Windows Servervariante nicht sauber über Windows Update.
Die OpenSSH-Version und die LibreSSL-Bibliothek haben auch schon einige Tage hinter sich.
Windows Server 2022 (Microsoft Windows [Version 10.0.20348.1547])
PS C:\> ssh -v localhost
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Windows Server 2019 (Microsoft Windows [Version 10.0.17763.4010])
PS C:\ > ssh -v localhost
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
Gruß
Wir haben Juli 2023, es hat sich nichts geändert – ich habe es im Beitrag OpenSSH, die Schwachstellen (CVE-2023-38408) und fehlende Patches in Windows sowie PowerBI aufgegriffen.
MIttlerweile hat \windows\system32\curl.exe die aktuelle Version 8.0.1.