iracigt

Curiosity. Calling it "node2shell" is a pretty strong claim. It is clearly the type of bug that can lead to code execution. What it takes to get there in the context of an http request is less clear.

As a practical matter, the impact could be pretty low. Very few things would accept brotli encoded data from a client. A PoC also doesn’t have to be for any particularly common configuration.

I’m someone who really enjoys reading Google’s Project Zero blog posts where they regularly walk through building exploits for phones and browsers. It gives you an appreciation for what is possible.

I had some fun playing with this on Wednesday. After the node release, it was still about a day before the patched brotli package showed up on pypi.

Very easy to reproduce the with a single httpx.get(URL) in Python, but I couldn’t figure out an ASLR bypass from that context. Crashing is easy and I (with LLM assistance) can get some read/write primitives, but no chain into getting a function pointer where I needed it. Probably needs heap manipulation, but I lost interest at that point.

Really hoping we see an actual RCE PoC. Also, the open weight models can easily provide a "regression test" that would shoo away most crawlers.

Generally, yes. Journals expect that the research is new. With most research labs (at least in CS) making their work freely available on the internet, the major value of publication is peer review. In my area, double-blind review is the norm, meaning the reviewers and authors don't know who the other is. Thus it's not clear to the reviewers if the prior research is even yours.

The expectation is you cite the previous work to clearly indicate it is not new, and that your submission for review is mostly about new research. In some situations overlap is okay, e.g. there's a conference version and then a journal version with additional results. In that case you disclose in writing what the delta is to the editor (who knows your identity while the reviewers do not). This also means in the paper you have to treat the prior work as if it is by a different group to maintain double-blind review.

The point is to make it clear what is new research. Trying to get credit for the same research multiple times, and boost citation count, is dishonest to the expectations of the community. It's also a waste of time for reviewers (who volunteer) to review same research over and over again after deciding it's acceptable. Think of it like a OSS maintainer getting pull requests for trivial changes to the code just to boost the green squares on someone's GitHub profile. It's a drain on everyone else and doesn't benefit the project.

This book in particular is primarily about error correcting codes.

Take a message we want to communicate and add some additional data that allows recovering the message even if part of it is corrupted. The hard part is choosing what additional data to include to recover from enough corruption with small overhead and in a reasonable runtime.

These are used everywhere from WiFi to hard drives to QR codes to RAM chips -- the ECC in ECC RAM being "error correcting code" and now partially mandatory with DDR5.

It's the essence of coding theory, not necessarily what's essential for all CS students to know.

One of the authors is at my university and teaches from this book. It's a math heavy upper-undergrad elective course. A couple percent of our students take it, usually in their final year of a 4 year computer science program.

The couple students I know who've taken it did enjoy it. They were also people who liked proof based mathematics in general.

WebUSB requires the device to opt in via it's USB descriptors. Otherwise any USB device with firmware updates would have this problem.

Maybe an issue here is WebSerial, as HCI comes over a serial port device. I believe the OS should block access to the serial device once the host driver takes it as a Bluetooth adapter though.

The devices are sold as programmable. The supplier loads their own code and has complete control over it. This is an advertised feature. Espressif also releases code that makes it into a Bluetooth adapter with a standard interface. Anyone in the supply chain can change the firmware without these commands. The concern is these commands were undocumented and exposed over an interface usually accessible by applications. The host drvier probably didn't expect this interface could make permanent changes.

ESP32 devices not using the Bluetooth adapter firmware are unaffected and already running custom closed source (possibly encrypted) code from the supplier.

Yeah, the research is good. Software developers do not expect HCI to have this type of control. Because it's undocumented, it's not in their threat model and is unexpectedly available from userspace. "Backdoor" isn't wrong, but it is misleading. The threat here is persistence from context that wasn't expected to have this capability.

Because it's not remote. This allows a computer with a Bluetooth adapter to debug and modify its own firmware. This is normal. The potential problem is the interface for this was not documented, and the commands are embedded in the HCI host-to-bluetooth-adapter protocol. Because it's undocumented, software developers on the host may not have considered this in their threat modeling. Firmware updates usually require kernel-level privileges, but HCI does not.

Oh, and from the perspective of open hardware, these alarmist headlines are a real disservice. The natural reaction to debugging interfaces and firmware updates being "backdoors" and "security vulnerabilities" is to lock it all down.

Espressif has been an almost unique level of open for this space. They've contributed to open source Rust toolchains for their chips. They've even publicly encouraged reverse engineering of their modem stack because it contains licensed code they can't release. I hate to see bad and damaging publicity be the reward for being just a little bit open.

Agreed. This is pretty common and no worse than a firmware update. The potential catch is in-band debugging may not require the same privileges on the host you'd expect from a firmware update. So conceivably your userspace (or worse WebBLE, not sure) program could add some malicious payload that's persistent in the adapter. Tracking beacon that persists through a drive replacement is scary, but not an RCE

I think the title is a bit misleading. If I'm reading correctly, the "backdoor" allows a computer to peek and poke memory and other low-level functions of its own USB Bluetooth adapter. I don't this this is usable over the air?

Undocumented debugging commands like this are common. I've worked with at least two chips, a WiFi adapter and a GPS receiver, that had similar functions. Neither was documented, but found by reverse engineering the chip firmware or vendor drivers. It's not exactly an impactful issue on its own. Anything that allows unsigned firmware is equally vulnerable.

If I'm misunderstanding and this is usable from anything other than the host, that would be a very different story.

Section 2.4 gives a concrete example, though there are some asterisks. The example is one where a compiler rewrites something like `while (...) x++;` to put `x` in a register: `int reg = x; while (...) reg++; x = reg`. The author reports this is an optimization GCC was observed doing, and means you can have a read-writeback even when the while condition is false to begin with. If this optimization appears interleaved with identical writes then you have problems.