Node2Shell evolves to HTTP2Shell, blast radius affects many HTTP libs and apps

est

wtf Python is also effected. https://pypi.org/project/brotli/ not sure about shell

tetha

Well at least we know about it while or before the giant patch effort for everything else goes on. Just put it onto the pile. Who turned on hard mode this week?

netsharc

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? You might as well call it Exploit Pro Max...

davedx

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?

nairboon

Brotli2Shell seems to be a more appropriate name for this.

cowsandmilk

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.

flyingjoe

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.

upofadown

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...

TacticalCoder

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?

Rapzid

> reported it as unauthenticated remote code execution that works in both directions > 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?

bawolff

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)

jgalt212

How may web servers only serve brotli? How many clients only accept brotli?

skeledrew

I've just been pointing a Claude Code at these things as they pop up. A great time to not have to worry about chasing all these things manually.

pimterry

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.

perching_aix

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.

austin-cheney

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.

rfgplk

As I've mentioned numerous times at this point, relying on third party code is a massive liability (supply chain attacks/sloppy code). My hand rolled brotli implementation is not only faster than libbrotli but also immune to this vulnerability (yes, I checked). Roll your own code people.

semiquaver

Let’s say I have a node.js app behind an Amazon elastic load balancer which terminates TLS. My understanding is that in nearly all configurations, my app would be unaffected because the ELB would handle decompression. Is that generally correct?

anttihaapala

I had to check all of our Python deployments and installation BOMs and was quite relieved - turns out that none actually installed brotli libraries. HTTP libraries like httpx, requests and frameworks consider them optional and autodetect their presence.

1vuio0pswjnm7

"In 2016, the Brotli algorithm shipped in Chrome, delivering overall better compression ratios for eligible resources." "By the end of 2017, all modern browsers supported Brotli, and server support for it started to become more widespread." For www users, all that data collection, surveillance and ad services traffic to enrich so-called "tech" companies acting as intermediaries, can make the www exceedingly slow The way to "make the web faster" (or less inefficient) is to get rid of that needless traffic, and the ads it supports SPDY,^1 HTTP/2 Server Push,^2 HTTP/3 QPACK,^3 brotli, .... make www users ("ad targets" to Google) uninformed, nonconsenting subjects in Google's failed experiments The www already works just fine for its intended purpose (_not_ data collection, surveillance and ad services) 1. "As of 2021, no major browsers supported SPDY" https://en.wikipedia.org/wiki/SPDY 2. https://en.wikipedia.org/wiki/HTTP/2_Server_Push 3. https://foxio.io/blog/header-accordions-qpack-amplification-...