this post was submitted on 15 Feb 2024
205 points (97.2% liked)
Open Source
31358 readers
191 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
For the record I agree with @[email protected], but I also want to add that a DoS is not necessarily a security risk. If it can be leveraged to expose sensitive information, then yes, that's a vulnerability; this isn't that.
Digging into the CVEs:
CVE-2024-24989:
CVE-2024-24990 basically says the same.
Some choice clauses:
So it doesn't take down the server nor the parent process, it kills some threads which then... restart.
I was able to find that the affected versions:
NGINX Plus R30 P2 and R31 P1
Open source subscription R5 P2 and R6 P1 Open source mainline version 1.25.4
but most importantly:
And saving me the hassle of linking and quoting all 5 of the version history pages for the affected products, the uniting factor is: they're all based on Open Source versions 1.25.*
None of them are using the latest stable version.
It's not even going to affect most sites, and definitely not ones for whom downtime is a major issue: they would not be using the non-stable version, much less enabling experimental features in a non-stable version.
But the part that irks me the most is the dillution of what a CVE is. Back in the day, it meant "something that can lead to security breaches," now it just seems to mean "hey guys, I found a bug." And that's bad because now you have one of two outcomes: 1. unnecessarily panicking users by leading them to believe their software is a security risk when it isn't, or 2. compromising the integrity and usability of CVE reports by drowing the important ones in waves of "look guys, the program crashes when I can leverage root privileges to send it SIGKILL!"
If this was just a bug hunter trying to get paid, that's one thing, but these were internally assigned and disclosed. This was an inside job. And they either ignored or never consulted the actual experts, the ones they have within their own staff: the devs.
Why? To what end? Did they feel left out, what with not having any CVEs since 2022? Does this play some internal political struggle chess move? Do they just hate the idea of clear and unambiguous communication of major security holes to the general public? Are they trying to disrupt their own users' faith in their paid products? Does someone actually think a DoS is the worst thing that can happen? Is there an upper level manager running their own 1.25 instance that needs this fixed out-of-band?
It's just all so asinine.
Do note that despite not being enabled by default, it is enabled in the official binary packages.
There's a funny amount of layers to this thing but as far as I'm concerned, if it's a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it's disabled by default.
Thank you for digging this out. Turns out it's even worse than what I gleaned from my surface-level take.
Thanks for this. I get now why the devs are pissed.