The Microsoft way (part 86): shipping rotten software | Hacker News Reader

The Microsoft way (part 86): shipping rotten software

seclists.org

25 pointsCTOSian12 comments

There is no incentive for Microsoft to modify their shipping patterns. Buyers consistently reward them by not only buying their software in immense quantities but also by paying exorbiant amounts of money for security software and services on top, of course of the MSFT brand. And then the cycle is completed by publicly celebrating them on their threat intel reporting, generated by their own products, sourced by actors abusing their own platforms.

It would be incredibly beautiful if it wasn't morally completely wrong.

Folks act like this is a unique problem/behavior by Microsoft. It’s not - as an industry we aren’t held accountable for collectively mostly treating security issues as an afterthought.

Sure, but msft is #1 offender of this dynamic by far

Probably that is because these three cURL issues are quite convoluted for an attacker to exploit, and so the issue has seen less urgency at Microsoft:

- https://curl.se/docs/CVE-2023-38039.html => that one is a resource exhaustion that needs the victim to connect to a malicious server intentionally

- https://curl.se/docs/CVE-2023-38545.html => that one needs a way for the attacker to control the target hostname and the victim needs to use SOCKS5, which in itself is incredibly rare. Never seen it either in BigCo or government environments, I only remember that from a decade ago when dabbling in warez.

- https://curl.se/docs/CVE-2023-38546.html => that one only affects people using libcurl or its bindings directly, and use the `duphandle` function, which is why it's ranked "Low" in severity.

> needs to use SOCKS5, which in itself is incredibly rare. Never seen it either in BigCo

Anecdata: We use a SOCKS5 proxy for some internal plumbing, though not in a context where curl/libcurl are at all relevant. I've seen reference to it elsewhere in recent times, so “incredibly rare” might be somewhat an overstatement.

But I agree with your assessment that these issues do not seem to be high priority. Also two of them are down as affecting v8.3 so were only addressed in an upstream release one week ago.

A bit of fun whatabautism: I've tried unsubscribing from mailing list, it required to login. I've asked it to reset my password, it send me my old password over email as a reminder.

curl 8.2.1 in insider since 2023-10-05 (not advocating, just FYI): https://winbindex.m417z.com/?arch=insider&file=curl.exe

All three of the mentioned CVEs are affecting 8.2.1. Even 8.3.0 is affected by 2 of them still. The latest version (8.4.0) is the only one that is not affected by these.

This is just terrible and inexcusable.

I would want to like Microsoft but time and again they prove they pay no attention to security and privacy related issues. The same with Azure too along with it being too slow and buggy.

I would read a lot more CVE if they were written by this guy. It's beautiful like a Kafka novel.

TIL Microsoft ships curl.

It is saying that the version being shipped is from 2023-Mar-20 and that there are vulnerabilities that have since been patched, which would allow a malicious server to DoS your client¹, cause a buffer overflow², or inject cookies³.

Though in fairness to MS two of those issues were only addressed in the latest version, released a week ago, despite them being raised in October last year some months before the release MS are currently using, and the other was addressed in the previous release about a month ago. I suspect a great many other places are sill not up-to-date on those given how many products bundle or otherwise depend upon libcurl (a quick check shows Debian have backported the updates into the version they have in the stable release, so at least some significant players are certainly doing better).

Also, there isn't evidence of any checking to see if MS are releasing stock cur/libcurl or if they have back-ported subsequent fixes like Debian do. Before a post with the sensational headline “shipping rotten software to billions of unsuspecting customers” I'd like to think that such cursory checks would be done and information about the results included in the post (especially if they came back in a way that looks negative for MS!).

[1] CVE-2023-38039 - sev=medium

[2] CVE-2023-38545 - sev=high - without more digging I can't tell from that if this would just make curl or an application using libcurl fall over, or if there is worse potential like RCE

[3] CVE-2023-38546 - sev=low

Reply on news.ycombinator.com