Well, whoever picked the name HTTP2Shell certainly didn't use any intelligence, artificial or genuine.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
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)
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.
Much prefer the Broccoli2Shell name & site (for the same vuln): https://broccoli2shell.com/. For starters, I'm pretty sure you can hit this without HTTP if you do any manual Brotli decoding, HTTP just happens to be the most common case that comes up.
A few month ago, everyone was advising to use cool-downs in your package upgrades. Now we're constantly overriding those because security incidents will be exploited immediately.
Guess that's just how it's gonna be from now on.
Article claims OpenAI found this in February, but I don’t think that’s correct. I think Google made a change to the Brotli source code in February that fixes the issue, but hadn’t realized it was a security issue and therefore hadn’t cut a release.
An example of the cost of added complexity I suppose. Brotli is much more complicated than the gzip/deflate it replaces. ... and of course we still have to expose gzip to attack as well.
Every time you add something you lose something...
Honestly it's time to get rid of C as a language used where security is a factor. Enough already. Why the hell is a lib like brotli that processes public general internet traffic, and maintained by google, not in rust?
I really don't understand how so many different things are affected by the same brotli bug/exploit.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Yes. All these language runtimes compile against common libraries. Compression libs are one of the most common common libraries that platforms like node, ruby, dotnet, python, and etc need to compile.
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.
It's so meaningless, broad and undescriptive of the actual issue. No it probably doesn't affect an HTTP server with nothing else behind it, so why is HTTP being blasted?
You might as well call it Exploit Pro Max...
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)
So as a hotfix I block this on my reverse proxy.
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.
Who turned on hard mode this week?
> but it wasn't recognized as a security issue at the time and no release shipped with the fix until now
I'm always getting my dangerous RCE bugs mixed up with my harmless RCE bugs.
I'm curious how this was reported and fixed back in Feb but nobody recognized the importance. A case of AI automation and nobody at the wheel?
Maybe an LLM just happened to do one of those "while I'm here" fixes in Feb and because nobody reviews anything anymore..
"Fixed reading too many bytes."
LGTM!
Edit: I was close! "Detect and report invalid stream earlier." Could have been a person.
Every time you add something you lose something...
> Security notice: Upgrade certifi, pip, and uv in response to CA certificate incident
Blimey PIP is affected? That's bad. I feel like that should have been bigger news?
There is a cost to conversion.
How many clients only accept brotli?
So say you run a SaaS that allows for something like letting people set their Avatar from an image URL which gets downloaded.
As an attacker I setup a new server that serves only brotli and then submit that URL to the SaaS.
That's a clever example, but why would you do that? The avatar should be a static resource. As such, I'd only provide an upload file dialog.
I even read the patch for the C code (patch which, btw, seems a bit hacky to me with isSafe? methods added and whatnots but YMMV: now I understand things had to be patched in a hurry but this patch really looks like "lipstick on a buffer overflowing C pig" to me).
What's the link between Python / Node / C++ / libbrotli / Envoy / Bun: are those some all using the same C brotli encoder/decoder?
Can someone who knows more explain why all those are vulnerable?
> As for unaffected software, Apache’s standard mod_brotli does not decode Brotli
Because this one only encodes and doesn't decode and the bug is in the decoder? (for I take it mod_brotli, with such a name, still does something brotli related and isn't, say, a TOTP token generator nor a SAT solver?).
I mean overall, sheesh: could we get better explanation / better writeups when such big fuckups happen?
Google provides the Brotli implementation. Package maintainers slurp that up and create ie libbrotli-dev. When you compile node it uses that for brotli support.