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 UEFI 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.

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 2.x that is extremely fast reading the BIOS contents (takes a few minutes). This was a great improvement versus BusPirate which took hours to just read the BIOS 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).

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 is lock 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:

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, a MacBook Pro 8,2, and a MacBook Air, all running latest EFI firmware available. And every single one is 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 ;-).

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 ;-).