Comment by bawolff
21 hours ago
To me, the surprising part is how many of these implement brotli compression of request (not just response) bodies, given how obscure a feature that is.
In any case all this sensationalism is starting to get annoying. Patch your stuff and move on.
Edit: actually, between all the sensationalism, its hard to tell from the article how many of these actually support brotli compressed request bodies in common configs vs some other use of brotli (which is bad but nowhere near as critical)
I think the issue is that the servers "silently" support brotli. Then nobody uses it, but the attacker can still abuse the feature.
So as a hotfix I block this on my reverse proxy.
But is that actually true?
It seems like node supports it with body parser enabled.
But im having trouble finding any docs suggesting anything else supports it on inbound requests.
Obviously there are other scenarios where it is exploitable, but it is a much less severe vuln if the attacker must first force the program to make an outbound request to a server of its chosing rather than just connect to a vulnerable server.
The idea is to identify brotli encoding in the content-encoding header and block that on nginx. This shouldn't reach vulnerable brotli parser in node.
I hope my assets are not connecting to malicious servers, otherwise yes, I have a problem.
Asp.Net adds Brotli support if you "UseRequestDecompression" or "UseResponseCompression".
DotNet, however, has it's own C# Brotli implementation.
According to Claude when I asked it to audit one of our Python applications, there are scenarios where Brolti can be used only when some Python library detects that the C library is installed on the system. So your Brolti-ness can depend on which machine your code runs on. Ymmv, it didn't look to be a practical possibility in our code so I didn't probe further.
3 replies →
I wonder if we'll see more of this thanks to AI. Extremely complex features that nobody uses and that were easy to add, which incidentally tremendously expand the attack surface. One would hope that maintainer would be wise to avoid that, but for how long?
https://github.com/tmux/tmux/pull/5709/changes it is already happening. Nice 50 lines of C-code to add support for kernel-keyrings which no userland software uses and literally is a one-line config-option.
I think so, especially vibe coded software. I think hackers have the advantage now and defenders need to limit attack surface more rigorously.
Unfortunately that means understanding and limiting dependencies of developers... Yea, good luck.
My popcorn is ready. My servers are not.
2 replies →
Cloudflare has this amazing feature where it accepts compressed payloads and forwards them to unsuspecting backends. Can be weaponized in many ways.
My experience with Brotli is from back when all the hype was mobile first and India etc was super mobile first so all these social networks lost their mind optimizing for request success and speed. So they were going crazy over micro-wins like that.