Elsewhere in this thread, they note that anyone decoding brotli responses is vulnerable, which would impact Apache/nginx conditionally; I can think of load balancer / proxy scenarios where that’s the case, as well as dynamic IP blocklisting as some use in-server, so duly noted for HN sysadmins.
Bender 2 days ago [-]
The nginx brotli module compresses outbound traffic. How would someone exploit brotli on nginx in this scenario? Is there PoC code that could be used against an nginx server that has the Brotli module enabled?
altairprime 2 days ago [-]
If you combine nginx brotli with nginx reverse proxy to a backend server that uses brotli-compressed responses, then you would have an opportunity for attack through this mechanism, assuming you could get your payload through both layers and back.
cowlevel 2 days ago [-]
Just compress your POST request payload with it. The endpoint doesn't even have to accept POST requests
TFNA 2 days ago [-]
Brotli is packaged along with MuPDF source code, too, and built as part of the MuPDF package by default.
cookiengineer 15 hours ago [-]
Remember yesterday, when all the top comments here claimed that "no real software is affected by this"? The same folks who wrote that the PHP RCE isn't real and downvoted everyone claiming otherwise?
> A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c)
It sure sounds like lately it's not a great time to be a C lover with a deep hatred on Rust...
And as a sidenote such exploits based on bugs in decoders is one of the main reason projects don't want to add support for every format under the sun (for example potential exploits has been invoked as a reason to not adopt jpeg-xl in a timely manner).
But yeah: maybe, just maybe, that C afficionados could concede that a language making buffer overflows impossible is actually a good thing? Instead of resorting to logical fallacies which are basically: "There are exploits for any single language out there, hence every language is equally likely to have buffer overflows".
cedws 12 hours ago [-]
I don’t get why Anthropic hasn’t already vibe ported all of this critical C code to Rust. If they claim LLMs can autonomously do ‘good’ language ports like they did with Bun, there’s pretty much nothing better they could do for the world’s security posture than eliminate dangerous C code. Why even have these cyber programs and then not do the most obvious beneficial thing possible?
cowlevel 2 days ago [-]
We should demand them all to be written in WUFFS (not a joke)
rasz 2 days ago [-]
>decode.c
What was that meme? "No Way to Prevent This, Says Only x Where This Regularly Happens" and from Google no less. Rare case of Mozilla W demanding JPEG XL decoder not be in C.
[0] https://infosec.exchange/@harrysintonen/117489564359709891
[1] https://infosec.exchange/@harrysintonen/117489801970908776
Where are all those folks now?
For reference (the thread I am talking about): https://news.ycombinator.com/item?id=50219177
It sure sounds like lately it's not a great time to be a C lover with a deep hatred on Rust...
And as a sidenote such exploits based on bugs in decoders is one of the main reason projects don't want to add support for every format under the sun (for example potential exploits has been invoked as a reason to not adopt jpeg-xl in a timely manner).
But yeah: maybe, just maybe, that C afficionados could concede that a language making buffer overflows impossible is actually a good thing? Instead of resorting to logical fallacies which are basically: "There are exploits for any single language out there, hence every language is equally likely to have buffer overflows".
What was that meme? "No Way to Prevent This, Says Only x Where This Regularly Happens" and from Google no less. Rare case of Mozilla W demanding JPEG XL decoder not be in C.
https://xeiaso.net/shitposts/no-way-to-prevent-this/memory-s...