Comment by ArcHound
1 day ago
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.
1 day ago
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.
These chat bots always hedge like that. They will never give you a straight answer, it's always "depending on version and build configuration and system configuration".
Investigate yourself. Read the documentation. Grep for brotli in the source. Don't blindly trust a chat bot when it says it "might happen in certain configurations".
2 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.
I'm not saying that my experience translates 1:1. As a child of domestic violence, all I can say is that it never gets better. Sadly, my feeling is that the violence will only escalate from here. If you look at the bright side, you can earn your stripes as a legitimate infosec engineer and prove your worth to the industry and the world.
1 reply →
Cloudflare has this amazing feature where it accepts compressed payloads and forwards them to unsuspecting backends. Can be weaponized in many ways.