[personal profile] mjg59
This is currently the top story on the Linux subreddit. It links to this Tweet which demonstrates using a System Management Mode backdoor to perform privilege escalation under Linux. This is not a story.

But first, some background. System Management Mode (SMM) is a feature in most x86 processors since the 386SL back in 1990. It allows for certain events to cause the CPU to stop executing the OS, jump to an area of hidden RAM and execute code there instead, and then hand off back to the OS without the OS knowing what just happened. This allows you to do things like hardware emulation (SMM is used to make USB keyboards look like PS/2 keyboards before the OS loads a USB driver), fan control (SMM will run even if the OS has crashed and lets you avoid the cost of an additional chip to turn the fan on and off) or even more complicated power management (some server vendors use SMM to read performance counters in the CPU and adjust the memory and CPU clocks without the OS interfering).

In summary, SMM is a way to run a bunch of non-free code that probably does a worse job than your OS does in most cases, but is occasionally helpful (it's how your laptop prevents random userspace from overwriting your firmware, for instance). And since the RAM that contains the SMM code is hidden from the OS, there's no way to audit what it does. Unsurprisingly, it's an interesting vector to insert malware into - you could configure it so that a process can trigger SMM and then have the resulting SMM code find that process's credentials structure and change it so it's running as root.

And that's what Dmytro has done - he's written code that sits in that hidden area of RAM and can be triggered to modify the state of the running OS. But he's modified his own firmware in order to do that, which isn't something that's possible without finding an existing vulnerability in either the OS or (or more recently, and) the firmware. It's an excellent demonstration that what we knew to be theoretically possible is practically possible, but it's not evidence of such a backdoor being widely deployed.

What would that evidence look like? It's more difficult to analyse binary code than source, but it would still be possible to trace firmware to observe everything that's dropped into the SMM RAM area and pull it apart. Sufficiently subtle backdoors would still be hard to find, but enough effort would probably uncover them. A PC motherboard vendor managed to leave the source code to their firmware on an open FTP server and copies leaked into the wild - if there's a ubiquitous backdoor, we'd expect to see it there.

But still, the fact that system firmware is mostly entirely closed is still a problem in engendering trust - the means to inspect large quantities binary code for vulnerabilities is still beyond the vast majority of skilled developers, let alone the average user. Free firmware such as Coreboot gets part way to solving this but still doesn't solve the case of the pre-flashed firmware being backdoored and then installing the backdoor into any new firmware you flash.

This specific case may be based on a misunderstanding of Dmytro's work, but figuring out ways to make it easier for users to trust that their firmware is tamper free is going to be increasingly important over the next few years. I have some ideas in that area and I hope to have them working in the near future.

Date: 2015-05-27 07:53 am (UTC)
From: [personal profile] jewelfox
I wish you luck!

Also that was a very good explanation I think.


Date: 2015-05-27 11:02 am (UTC)
From: (Anonymous)
Useful write-up; thanks. What kind of resource constraints would SMM malware have? Must it be necessarily tailored for a particular OS/version; or can it be complex enough to contain exploits for multiple OS/versions and adapt to whatever's running?

"still doesn't solve the case of the pre-flashed firmware being backdoored and then installing the backdoor into any new firmware you flash"
... but flashing Coreboot/Libreboot with a 'trusted' external programmer clamped to the flash chip, that would still work?

"make it easier for users to trust that their firmware is tamper free"
I'd argue the other way. Keep firmware simple, don't try to tamper-proof it; make it easier to flash it upon purchase with something trusted, and as often as you feel necessary after that. Thereafter, run an operating system that you trust to protect it from tampering.


Date: 2015-05-27 11:05 am (UTC)
From: (Anonymous)
> the means to inspect large quantities binary code for vulnerabilities is still beyond the vast majority of skilled developers

Let me FTFY...

the means to inspect large quantities code for vulnerabilities (openssl for example) is still beyond the vast majority of skilled developers

Coreboot ubiquity

Date: 2015-05-27 12:09 pm (UTC)
From: (Anonymous)
I wonder, how far is the use of Coreboot by savvy users?

Re: Coreboot ubiquity

Date: 2015-05-27 01:46 pm (UTC)
From: (Anonymous)
For some thinkpad models you have to open the device and flash the chip on the model for others like the x200s you have to solder a new flash chip onto the board.

Date: 2015-05-27 04:07 pm (UTC)
From: (Anonymous)
I wouldn't call this anything new. The fact that you can store data in memory shouldn't be shocking. I'm more concerned with this: http://www.pcworld.com/article/2901262/microsoft-tightens-windows-10s-secure-boot-screws-where-does-that-leave-linux.html and how it well affect linux and the community.

Yes indeed

Date: 2015-05-27 05:21 pm (UTC)
From: (Anonymous)
It's easy to misread a lot of the publicity on this and think that, oh damn, an actual hole's been found in a real UEFI implementation. What's actually been done is... less exciting than it appears, and totally unsurprising to anyone who knows and hates SMM already. It's still a useful proof of concept though.

(However... this might let us get a look at SMRAM on real systems, which would be nice.)

fart fart fart

Date: 2015-05-27 05:34 pm (UTC)
From: (Anonymous)
fart fart fart fart fart

Date: 2015-05-28 05:48 pm (UTC)
From: (Anonymous)
What's Dimitro doing now is a SMM payload development. Yes, he has modified the firmware to develop and debug it, but at the end it will be a simple SMM driver, so you only need to add this ready-to-use code into the firmware, which is a different and easier task. At first, you need local privilege escalation to get to physical memory and SPI interface. If it's unprotected - you are done here, dump BIOS region using flashrom, modify it with uefi-firmware-parser to integrate the driver and flash the modified image back into the flash. Bang, you're pwned.
If SPI flash is protected from writing, there are numerous attacks on this protection, including S3 BootScript vulnerability (which isn't fixed for like 95% of the current UEFI-based systems) and a ton of SMI handlers vulns (unvalidated buffers that cross SMRAM borders, execution of non-SMRAM code from SMI handler, you name it). Yes, it should be a targeted attack for now, but UEFI is all about code reuse, so if someone really wants to get into your UEFI - there is nothing you can do about it (except BootGuard, maybe, but it's a whole different story).

There is no need to panic and/or blame UEFI developers, but there is also much to be done about UEFI security, starting from patching existing vulnerabilities reported 6 months ago, reducing attack surface for flashing software (Intel PFAT, capsule-based updates, etc.), using hardware root of trust (BootGuard/TrustZone) to measure and/or verify the firmware step by step, and so on.

As for you, normal user of UEFI system: "Please, please, please, go apply BIOS updates" --Xeno Kovah @ CanSecWest 2015.
From: (Anonymous)
Really, hell no.

I have too much experience with BIOS updates being hell to apply and bricking systems when they do, and I care much more that my system works than that it has no vulnerabilities. (My system will have vulnerabilities *anyway*, no matter whether I risk my neck by applying a BIOS update or not, so this is asking me to take a real risk of bricking on the order of thousand quid of hardware to solve a very small part of a larger problem. Thanks, but no thanks, not until updating BIOSes becomes as trivial and easy to roll back as updating kernels)

-- Nix

RAM, eh

Date: 2015-05-31 10:11 pm (UTC)
From: (Anonymous)
Is there something protecting the SMM goodies from being read by peripheral DMA, e.g. that lovely feature of FireWire? Perhaps an older motherboard might not have this?


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags