Thread by @moyix

The camera-ready version of our @IEEESSP 2022 paper, "IRQDebloat: Reducing Driver Attack Surface in Embedded Devices" (w/@highw4y2h3ll) is now available! messlab.moyix.net/papers/irqdebl…

The basic problem we're looking at in this paper is: if you buy some embedded/IoT device, it may come with a bunch of features that you don't use (say, Bluetooth) that nonetheless require driver support and expose unnecessary attack surface.

Maybe you're a company deploying a fleet of Meraki routers, you don't need the Bluetooth Low Energy localization stuff, and you're worried about vulnerabilities like this one arstechnica.com/information-te…

So we want to disable some hardware functionality by rewriting the firmware. The problem is, it's hard to do this in a way that generalizes to the myriad embedded OSes and different hardware platforms out there.

Key idea: almost all input from the outside world is delivered to an embedded system when some peripheral raises an interrupt, or IRQ. By focusing on automatically reverse engineering the IRQ handling for a device, we can enumerate IRQ sources and disable the ones we don't want!

IRQ handling usually looks something like this. The CPU has a small number (one or two) dedicated pins connected to an interrupt controller that multiplexes interrupts from individual peripherals. To support more peripherals, interrupt controllers can be chained together.

By exploring the interrupt handling code starting from the top-level handler, we can eventually discover the individual handlers for each peripheral! And once found, we can replace the ones we don't want with a small stub that just ignores the interrupt and returns.

We initially tried to do this with symbolic execution, but the liberal use of function pointers and privileged instructions (which most sym exec engines don't support) made this approach impractical. Instead, we use snapshot-based fuzzing.

We start by collecting a system-level snapshot (RAM and CPU regs) from the target embedded device. We then load this snapshot in an emulator (PANDA) and trigger a top-level interrupt. From there, we fuzz the interrupt handling by responding to memory-mapped with fuzzed inputs.

This fuzzing gives us a big collection of traces. Somewhere in there should be the actual handlers we want. How do we find them? The key observation is that the traces will differ from one another (diverge) when they branch off into the individual handlers–so we can "diff" them!

We borrow and extend a technique called execution indexing (Xin et al., PLDI '08) to compare traces and precisely identify handlers. Then all we have to do is disable each handler one at a time until we find the one the corresponds to the functionality we want to get rid of.

The big challenge with this paper is evaluation – there are tons of different embedded platforms running all sorts of OSes. We ended up choosing seven different devices, running four OSes across two CPU architectures (ARM and MIPS).

This is also why I have a giant pile of embedded junk sitting around my apartment now :p

https://twitter.com/moyix/status/1422296832835731463

The fuzzing patterns are very effective at uncovering the handlers! We were able to discover all handlers in our devices, except for two on the SABRE Lite that turned out to be already disabled. Most handlers are discovered within 3 hours of fuzzing.

We also did a detailed attack surface analysis on the Steam Link by looking at CVEs reported in the Linux kernel over the past 5 years and matching them to drivers on the device. We found that up to 44 kernel CVEs could have been mitigated depending on which IRQs were disabled.

To wrap up this thread, I want to thank my co-author Zhenghao (@highw4y2h3ll) who put in tons of work doing RE to establish ground truth for our evaluation and implementing the binary analyses we used. I'm very lucky to have him as my advisee!

@highw4y2h3ll This project took a *long* time to come to fruition—we started working on it in 2016! So I must also thank the undergrads and masters students I've worked with during that time, nibbling away at small pieces of the problem until we understood it well enough to build this.

@highw4y2h3ll You can find all our code and data (including sample memory and CPU snapshots for the evaluated devices) on GitHub: github.com/messlabnyu/irq…

And that's all, folks (though there are of of course many more details in the paper)! You can also read this thread all in one place with ThreadReaderApp: threadreaderapp.com/thread/1473695…