FYI: CVE-2024-11053 is *not* a critical security flaw, even if now several security related sites repeat that statement.

This is as good as any reminder that you should read the #curl advisories for #curl issues rather than trusting the scaremongers.

curl.se/docs/CVE-2024-11053.ht…

(edit: I wrote an extra '1' in there at first)

#curl
This entry was edited (8 months ago)

daniel:// stenberg:// reshared this.

in reply to daniel:// stenberg://

Ah. vulnrichment. cool... Almost looks like the intent of the project is to make vendors care and release their own data by being *somewhat * wrong *some of the time*.
We had a local password disclosure in Firefox for Android flagged as "remotely exploitable" and therefore "critical". Fixing was easy, at least. Even though I hate how this makes this another thing to care about. github.com/cisagov/vulnrichmen….
in reply to daniel:// stenberg://

It's not quite simple, but here's a way to exploit this:

* use an X ray gun to modify the Linux kernel source tree on Linus's personal machine to add a remote execution bug
* exploit that bug to infiltrate the SSD manufacturer to alter the firmware they put in their devices
* have that malware install firmware on the network card at the network card factory
* let the network care alter downloads of the Bash shell
* the altered Bash shell update .netrc when curl is invoked

Voila!

in reply to daniel:// stenberg://

it's immensely frustrating that something like that could block a deployment. If the redirect is managed by an endpoint _you've already passed the credentials to_. FFS. So much has to already be hijacked or sloppy (in either case, you probably already have problems) for this to be an issue that I'm at a loss. OTOH a quick search for the CVE (I think you added an extra 1? I found it as CVE-2024-11053) has given me a 'low' score. I guess you'll see more assessments than me though!
in reply to daniel:// stenberg://

We added your clarification in vulnerability-lookup.

vulnerability.circl.lu/cve/CVE…

Now I'm wondering if we should not add the ability to propose the author and maintainer to counter any element from a vulnerability description.

@cedric what do you think of it? Not sure how this could be efficiently implemented.

in reply to daniel:// stenberg://

I get why it’s important to have an independent severity rating for security flaws. Vendors are incentivized to downplay the severity. Does anybody think Adobe would have appropriately rated even *half* of the bugs in Flash?

But for the independent ratings to be useful, they need to have high quality with extreme consistency. We certainly don’t seem to be getting that.