![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59This 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.
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.
no subject
Date: 2015-05-27 07:53 am (UTC)Also that was a very good explanation I think.
Mitigations
Date: 2015-05-27 11:02 am (UTC)"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.
Hmm
Date: 2015-05-27 11:05 am (UTC)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)Re: Coreboot ubiquity
Date: 2015-05-27 01:46 pm (UTC)no subject
Date: 2015-05-27 04:07 pm (UTC)Yes indeed
Date: 2015-05-27 05:21 pm (UTC)(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)no subject
Date: 2015-05-28 05:48 pm (UTC)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.
This normal user of an UEFI system says 'hell no' to Xeno.
Date: 2015-05-29 03:22 pm (UTC)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)