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?
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.
Why are we still so reliant on HTTP? HTTP came out in 1990 (36 years ago) and the most common version of HTTP still in use, 1.1 (RFC2616), came out in 1999 (27 years ago)?
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
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.
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...
And strictly speaking you cannot trust the pip upgrade of pip with the vulnerable cert in the trust store due to certifi, which you also cannot upgrade safely with pip for the same reason. All of these are at one out of two compromises from being MITM'd during the upgrade.
So strictly we have to burn everything python to the ground and reinstall entirely.
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?
hey guys, fyi: git for windows is vulnerable even in its latest release (2.56.0.windows.3), careful pulling repos over https from random ass servers (prolly uncommon but hey). they already merged the fix on the repo, it's just in a snapshot build only; should prolly arrive on Monday (2.56.0.windows.4).
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
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?
Brotli was a library released by the Google team that developed it. There weren't lots of independent implementations; they were all from the same source code.
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...
Yes, I know HTTP 2 and 3 and SSE are attempts to make it faster and more parallel, but its still slow. Its slow because its unidirectional with a full round trip and by default its a new socket per each message. Yes, I know the real reason HTTP became and remains popular is because its sessionless... in theory. Still, there are better options available. You can do so much more with a full duplex channel.
If you want something else you can take your pick based on need from dozens of other options
> 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?
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?
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?
So strictly we have to burn everything python to the ground and reinstall entirely.
There is a cost to conversion.
also affects codex (gui), which ships its own git, could be more of a problem there, when the LLMs get quirky at night. still unlikely to be a problem though.
speaking of, update codex (and wipe its cache at ~/.cache/codex-runtimes), ships its own node. update python.
stuff like wireshark and imhex remain vulnerable, even on their latest repo commits, which may or may not be spicy.
also Microsoft 365 Copilot still has its own unpatched brotlidec.dll from Oct 7, if anyone uses that. no fix available for that one afaik, not sure about how it can be made to access the vulnerable decoder.
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.
Quit being overly pedantic about how contrived the example is and struggle with the underlying fact that the compression type is negotiated between the client and server. If the compression happens on the HTTP request (as some of the comments here suggest), then the server must use that compression method or it fails to read the body of the request.
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.