If you are a rootkits fan the latest Chaos Communication Congress (CCC) in 2014 brought us two excellent presentations, Thunderstrike by Trammell Hudson and Attacks on UEFI security, inspired by Darth Venami’s misery and Speed Racer by Rafal Wojtczuk and Corey Kallenberg.
The first one was related to the possibility to attack EFI from a Thunderbolt device, and the second had a very interesting vulnerability regarding the (U)EFI boot script table. The greatest thing about the second vulnerability is that it allows to unlock flash protections by modifying the boot script executed after a S3 suspend-resume cycle.
Dmytro Oleksiuk aka Cr4sh released proof of concept code regarding this attack against an Intel DQ77KB motherboard. His very interesting blog post is Exploiting UEFI boot script table vulnerability. You should definitely read it.
My interest in EFI has been mostly about unlocking a firmware password that I forgot. While Trammell didn’t release the proof of concept code for Thunderstrike he did release an awesome tool, a SPI Flash reader for Teensy that is extremely fast reading the firmware flash contents (takes a few minutes). This was a great improvement versus BusPirate which took hours to just read the flash memory. Months before I tried to get into EFI world but the BusPirate was so slow it was impossible to use it for trial and error testing. The new tool got my interest back into EFI. Anyway, enough bla bla.
Trammell on his presentation mentioned the possiblity that Macs could also be vulnerable to the Dark Jedi attack. After Cr4sh blog post I decided to give it a try and explore the same attack.
The attack requires you to reverse the boot script implementation, which is a royal pain in the ass. EFI binaries are a bit annoying to reverse even with the assistance of Snare’s EFI utils. IDA also has some bugs regarding EFI binaries.
While doing some experiments with flashrom I finally noticed something big. I couldn’t believe it the first time so I tried it in other Macs and it was indeed true. Macs have an even bigger hole than Dark Jedi.
Drum roll…
What is that hole after all? Is Dark Jedi hard to achieve on Macs?
No, it’s extremely easy because Apple does all the dirty work for you. What the hell am I talking about?
Well, Apple’s S3 suspend-resume implementation is so f*cked up that they will leave the flash protections unlocked after a suspend-resume cycle. !?#$&#%&!#%&!#
And you ask, what the hell does this mean? It means that you can overwrite the contents of your BIOS from userland and rootkit EFI without any other trick other than a suspend-resume cycle, a kernel extension, flashrom, and root access.
Wait, am I saying Macs EFI can be rootkitted from userland without all the tricks from Thunderbolt that Trammell presented? Yes I am! And that is one hell of a hole 😃.
Let me show you how it happens. The following is the flashrom output of a freshly rebooted MacBook Pro Retina 10,1 running the latest EFI firmware available (this is the firmware that was released to fix Thunderstrike).
sh-3.2# ./flashrom -r biosdump -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x74: 0x866f0190 PR0: Warning: 0x00190000-0x0066ffff is read-only.
0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ffffff is read-only.
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x0606 (PREOP)
0x96: 0x3c6c (OPTYPE)
0x98: 0x0103029f (OPMENU)
0x9C: 0xffd82005 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)
What we can see here is that the flash lockdown is active (FLOCKDN=1) and that the BIOS region is mostly read-only. The hole that is writable is the NVRAM portion that is necessary for setting boot options, crash logs and so on. The addresses where EFI binaries are located are locked down by the flash protections (PR0/PR1). The Dark Jedi attack would allow to unlock these areas and make them writable.
After I close the MacBook and let it sleep for a few seconds (30 seconds or something is best, sometimes it doesn’t work and needs to sleep some extra time), we get the following flashrom output after waking up the machine:
sh-3.2# ./flashrom -r biosdump2 -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0x6008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0
Programming OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x5006 (PREOP)
0x96: 0x463b (OPTYPE)
0x98: 0x05d80302 (OPMENU)
0x9C: 0xc79f0190 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)
This time we have FLOCKDN=0 and the protected range registers (PR0/PR1) without any contents. The flash is unlocked and now you can use flashrom to update its contents from userland, including EFI binaries. It means Thunderstrike like rootkit strictly from userland.
Which Macs are vulnerable to this?
I have tested against a MacBook Pro Retina 10,1, a MacBook Pro 8,2, and a MacBook Air 5,1, all running latest EFI firmware available. And every single one is vulnerable. The Late 2013 Mac Pro (aka Trashcan), MacBook Pro 9,1 are also tested to be vulnerable.
It appears that latest MacBook models are not vulnerable but I’m not 100% sure about this. I couldn’t fully test it on a recent model (the owner was afraid of giving me root access). The first impression was that the bug was silently fixed by Apple but this requires extensive testing to be sure (or some EFI binary disassembling).
I expect all mid/late 2014 machines and newer to not be vulnerable. Apple either fixed it by accident or they know about it. It’s not something you just fix by accident, just sayin’.
I’m pretty sure Apple is aware of the bug or at least it would be quite irresponsible from them to not test if their BIOS implementation was vulnerable to the Dark Jedi attack. I had no issues doing PoC tests with it but definitely needs other people to test it out (at least to find which other Macs are vulnerable).
How can you protect yourself from this?
Do not let your computer sleep and always shutdown it.
You should also email Apple and demand firmware security fixes for this bug and others to be presented at Defcon 23 – ThunderStrike 2: Sith Strike.
This is not full protection since the full Dark Jedi is most probably still possible to execute. The only real fix is Apple to update the firmware.
Unfortunately I never finished reversing the S3 suspend-resume EFI binaries so I can’t show exactly where the bug is inside the code. It requires some improvements to current EFI reversing tools and other matters got higher priority than this.
There is also something funny. Flashrom requires DirectHW.kext to work. The funny thing is that this kext is on Apple’s exception list so no kext signature is required to load this one on Mavericks/Yosemite.
Oh, is this irresponsible disclosure? Well I’m pretty sure Apple knows about this one but I could be very wrong. I’m confident Corey and Trammell disclosed this one to Apple and they will discuss it on their upcoming Defcon talk. If I’m wrong I just wasted a nice and valuable bug. Ooops!!!!
Either way the goal is to pressure them to fix their firmware. It doesn’t seem they are in a hurry 😉.
Why no fancy logo and name? Well, because this is a variation of the Dark Jedi attack and I’m old school. I still believe knowledge should be shared for everyone to learn instead of PR whoring. And I already get enough PR from this blog.
Update:
It appears I miscalculated this thing and appears to be an effective 0day. Doesn’t really matter since I always wanted to disclose it and not sell it due to its very powerful nature (and not working in newer machines). Never assume all bugs are shallow.
You might ask if I am into something against Apple judging by the tone of some posts. I am not. I like OS X and I respect Apple security people who I met a few times. My goal is to make OS X better and more secure.
The issue at stake is that I believe Apple has a corporate culture problem regarding security (like Microsoft had many years ago) and they only seem to react when pushed against a corner. If they indeed knew about the bug – because I don’t believe it’s a coincidence not working in latest machines – then they keep their pattern of not patching older versions. This is a bad policy and at least if they want to put it in practice at least be straightforward with customers and warn them about the issues. People can then take informed decisions about their risks. Of course this is wishful thinking and they will not shoot their own foot coming forward with things like this. But that’s a philosophical discussion about management around the world and why it’s so wrong these days.
How can you mitigate/detect a possible EFI compromise?
You can build a SPI dumper and use Trammell’s software to directly dump the flash chip. Then you can compare its contents against the firmware files provided by Apple. I asked Apple to start publishing these files and their signatures so we can have a good baseline to compare against. Hopefully they will do this one day. I built some tools for this purpose but they aren’t public.
This solves the EFI problem but others are left. For example there is SMC. Alex Ionescu made a very interesting presentation about it a few years ago at NoSuchCon. SMC has a very interesting potential for compromise so it’s also something that needs more research. And now we have PoC regarding GPU rootkits. Every single chip that has firmware and somehow talks to the operating system is open for compromise. We need to think different and start a trust chain from hardware to software. Everyone is trying to solve problems starting from software when the hardware is built on top of weak foundations.
Apple has a great opportunity here because they control their full supply chain and their own designs. I hope they finally see the light and take over this great opportunity. Google is trying with Chromebook.
Is physical access required to exploit this bug?
No, there’s no physical access required to exploit this. You can trigger sleep with sudo pmset sleepnow (thanks Trammell). And then you just wait to come back from sleep and continue exploitation.
How to test for this bug?
Downloading DarwinDumper and load the DirectHW.kext kernel extension. Then you can use flashrom with flashrom -r biosdump -V -p internal to dump the bios and show the register contents. Else you can compile yourself DirectHW.kext and also flashrom. DarwinDumper just works out of the box and its kext appears to be legit (it’s on Apple exclusion list so at least Apple trusts it).
Should you be worried about this bug?
As a general user you shouldn’t, in theory, be much worried with this bug more than you were with Thunderstrike. This is a bug more interesting to attack targeted users than mass exploitation, although a drive-by exploit is definitely feasible.
There are easier and cheaper attacks available against you the general user. As a reminder the latest Mac botnet infected around 17k users just by asking them for administrator privileges. Sophisticated attacks are not required when simple things still work.
Have fun,
fG!
P.S.:
The bug can be used with a Safari or other remote vector to install an EFI rootkit without physical access. The only requirement is that a suspended happened in the current session. I haven’t researched but you could probably force the suspend and trigger this, all remotely. That’s pretty epic ownage 😃.