[coreboot] Remote security exploit in all 2008+ Intel platforms

[Youness Alaoui]

On Mon, May 1, 2017 at 7:22 PM, Taiidan at gmx.com <Taiidan at gmx.com> wrote:

> On 05/01/2017 06:44 PM, ron minnich wrote:
>
> On Mon, May 1, 2017 at 1:17 PM Rene Shuster <rene.shuster at bcsemail.org>
>> wrote:
>>
>> Yes Puri.sm has been debunked.
>>>
>>> I disagree. I've seen the systems. From what I can see, Puri.sm has made
>> a
>> good faith effort to go as far possible *with modern x86 chipsets* toward
>> getting rid of the blobs. They can't get to 100%, but they're trying to
>> get
>> as close as possible.
>>
>> ron
>>
> Name one thing that they have done themselves?
>
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem
> _laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the
> coreboot community being corrupted)
>
> Everything they "do" is someone elses code, and their "coreboot" has zero
> actual init code it is entirely blobbed.
>
> Their marketing is the only thing that is good.
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>

Without entering into a flamewar, you're asking "name one thing that they
have done themselves" and I will answer that.
Full disclaimer: I am working for Purism, and I have been a paid contractor
working since last December (part time initially, full time since March) on
bringing coreboot and the ME-disablement effort to the Librem line of
laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2
hardware which is set to be released/shipped next month).

First, here's a timeline of the coreboot work explained here :
https://puri.sm/coreboot/timeline/
That timeline mentions for example that the original port was made by
coreboot developers (which seems to be a huge scandal for some reason)
after Purism donated 4 laptops for that work.
You can also read my blog posts on what exactly I have done (in great
detail) in order to bring coreboot to the Librem (from the "I'm a total
n00b" to the "I'm still a n00b but slightly less") :
https://puri.sm/posts/diving-back-into-coreboot-development/
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
https://puri.sm/posts/preventing-interference-from-the-old-bios-while-flashing-coreboot/
There's also a pretty big article about NVMe issues that I'm (currently)
fixing, which is half-written and which I'd be happy to send you the link
to once it's published.

Ron couldn't be more right when he says that you can't appreciate how much
work it is to go from a "it works" to a "it's tested/verified and made into
a *product* for actual users". It took me 6 months of work to finish the 4
days of work that Duncan Laurie did (I believe it took him 4 days to do the
initial port, feel free to correct me if I'm mistaken, and yes of course, I
am totally new to the coreboot world, so a lot/most of that time was spent
on the learning curve).

You can also see my actual contributions to coreboot (and one unmerged to
SeaBIOS) here : https://review.coreboot.org/#/q/owner:%22Alaoui%22
I have also contributed in the past couple of weeks to flashrom by
reviewing and commenting in Nico Huber's branch which adds Skylake support
to flashrom : https://review.coreboot.org/#/q/topic:intel_chipset_support

Now that was the coreboot work that was done, here is the ME work that was
done :
While the me_cleaner was tested and verified to work on the Librem (see
here:
https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops/),
the actual work of me_cleaner was done by someone else, but the testing and
verification was still done by us, I think that counts for something. Also
note that an advantage of the librems here is that they come unfused which
is what allows me_cleaner to work on them (see
https://puri.sm/learn/intel-me/). Any laptop with the boot guard fuse
enabled will shut down immediatly if the ME is cleaned with me_cleaner.

For actual ME-related work that wasn't done by someone else, I will point
you to this file :
https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c
That is a full C re-implementation of the ROMP module (the smallest of the
two modules that me_cleaner does not remove).
This is the RAPI header it uses :
https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h
That code is a C reimplementation with every instruction accounted for. It
has not been compiled (it serves more as a proof of concept/pseudocode,
although it should probably compile), and it's not meant to generate a
binary-compatible file (that could be a long term goal to generate binary
compatible images from C source with official intel-provided images).
Note that I have done the entire Assembly->C conversion myself, but I do
want to give credit to Igor Skochinsky for his help (which saved me
weeks/months of work) as he shared his notes of his ME reverse engineering
efforts (memory layouts, RAPI structures and address->function_name
mappings, etc..)
This ROMP work and details about that work are also part of the pending
article that I mentioned earlier, so you'll get to read about it too if you
ever decide to read about my adventures dealing with NVMe.

Now this is what I, personally, have done as a contractor working for
Purism, since last December, and I'm not going to mention anything else
done by anyone else on the team. After all, you only asked for someone to
"name one thing".
I hope that answers your question Taiidan.

Now back to the ME exploit subject of this thread.
Something to take note of in that ROMP module (note that the binary is just
under 1KB of code), it has a bug where it passes the 'partition size'
directly as argument to the rom_lock_mem_range function, instead of passing
(size << 2) as argument. This causes 3/4th of the memory region not to be
locked (the partition size in the header is for some reason in 32-bits
units) and the module hashes are contained within that unlocked 3/4th
region, and this happens after the signature is verified. So yes, that
*could* be a really nice exploit to give us unsigned code execution, if we
were to modify some code and its corresponding hash in the unlocked memory
after signatures are checked and before the code is executed. Unfortunately
according to Igor, it can't be exploited, because this happens before the
DRAM is initialized, so it probably only happens in the internal RAM of the
ARC Core to which the main CPU doesn't have access anyways (maybe it can be
exploited differently, if the copy-to-dram also copies the region-locking
boundaries... remains to be seen when more is reversed/understood).

The really interesting part is that ROMP was one of the smallest modules
with less than 1KB of code, I wasn't expecting to find a bug/exploit in it,
but I just wanted to reverse it to get my feet wet, so to speak, since it
wast the smallest of the two that me_cleaner keeps. But ROMP already has
this bug, so what other bugs could we find in the 1.6MB of binaries that
the ME holds (or worse, in the 10MB version of the ME). I'm not at all
surprised that there was an exploit for all these years, the quality of
their code is probably not very high, I'm just surprised that it wasn't
released sooner.
After I'm done with my coreboot work (for the v2 hardware), I'll continue
reverse engineering the ME, and maybe something nice will come out of it.
Ultimately I hope we can get full unsigned code execution running, and full
auditable C code equivalent of any binary code that gets executed between
power-on and the exploit/custom code being executed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170501/e95778d0/attachment-0001.html>