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

Youness Alaoui kakaroto at kakaroto.homelinux.net
Wed May 3 01:39:31 CEST 2017


Looks like I failed at answering Taiidan without generating a flame war.
Sorry if anyone got offended, that wasn't my aim.
To answer the various questions that were thrown, here's what I think :

Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM or
whatever... Well, because that's not what most people want, out there. If
you want a RYF laptop using old or underpowered hardware or non-x86
architectures, that's a problem that has already been solved, there are
various resellers of such devices. The idea here is not to "Use what we can
find to make RYF" but rather "Bring RYF to the hardware that people want".
What I believe Purism is trying to do is to create a modern laptop for
*everyone* with the extra value of security and privacy, and in the process
make FLOSS appealing to mainstream instead of letting it be confined in a
niche. I think everyone will be better off with tools to protect their
privacy/security without asking them to throw the baby with the bathwater
by requiring them to use hardware that does not interest them (otherwise,
if old or non-x86 architectures were so appealing, you would have seen that
become the norm rather than the exception).

As for the ME and DMCA, I believe this exempts us from it :
https://www.ftc.gov/news-events/blogs/techftc/2016/10/
dmca-security-research-exemption-consumer-devices
...Considering that the research is done in order to protect users. Also,
an exploit to run a custom firmware on the ME isn't something that gives
access to copyrighted material, so I'm not sure why the DMCA would even
apply here.
As for your argument of an arms race and Intel "fixing" the weaknesses
allowing us to neutralize the ME, I don't see how that would matter either,
because you will be able to control the image on your own machine
*today*... if you neutralize it today, even if Intel wanted to take over
the ME in your system to patch it, well... they can't get in, because you
already neutralized it. And if they want to change it for future models,
they will have to change it in the silicon of future models, which is way
out in the future.

To answer Sam:
Thanks for the kudos! The reason C is used is because I didn't think to use
anything else. I love C and that's what I like to use. But beyond that
answer, there are many reasons for using C. It's because this is an
assembly to C translation, if the code is 'prone to errors' it's only
because the original ME binary instructions had those errors in it, which
is good for us, since we're looking for exploits. Also, the long term goal
is to be able to generate binary-compatible images (imagine, you compile
the ME source and get a binary with the same hash as the one intel is
providing, so you can be 100% sure that it's the same code that you're
auditing as the one that is running). If we were to use any high level
language, we would never have enough fine control over the resulting binary
to be able to get binary compatibility.

Zoran: Thanks for your comments and encouragement! :) the talks with Intel
as far as I know are not for open-sourcing the ME (which is a much harder
thing to ask for), but rather for a ME-less design. Basically, for Intel to
release a chip with the ME core simply disabled and with no firmware
running on it. That's a much easier goal to attain, but then again, we're
talking about Intel, so it's still a difficult goal to attain, but Todd has
been bugging them for a while and is constantly in talks with Intel to try
and achieve that.


to answer Nico's other post:
I'm quite surprised and disappointed by your answer. You have every right
to say that you are disappointed or distrusting Purism due to past actions,
but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
when that is not the case at all. I think Ron has responded quite well to
that and said exactly what I wanted to say, there is a difference between
being naive and underestimating the task, vs actively "trying to scam
people". If they were scamming people, they wouldn't have shipped any
product and they wouldn't have reimbursed those who changed their mind or
were unsatisfied with what they got, and actually, I wouldn't even have
been contracted in the first place.

Attributing to malice what was the result of honest mistakes, while you
know how complex this is both on the software and hardware side, is why
your tone was disappointing. Careless name-calling leads to people getting
hurt and flame wars and all that.

I would just like to answer you with a few more items that I believe are
true (I may be mistaken myself as I'm still quite new to Purism):

   - Everything that was promised is still on the roadmap and a
   work-in-progress (as far as I know), so it's more of an issue of missing
   the deadlines/estimates rather than not wanting to deliver anything that
   was promised. The "Vision" of the company in an initial crowdfunding
   campaign does not mean "this is an immediately attainable milestone".
   - The priority was to actually have a working product before working on
   its coreboot port (wouldn't you agree that makes more sense?) There were a
   ton of issues to solve with production/delivery to begin with, and Purism
   is understaffed (most are volunteers as far as I know, and people with the
   skills to do a coreboot port are quite rare, as you know... and some that
   Purism hired before went dark). It would have been useless to focus all
   efforts on coreboot for a hardware product in the making. Purism brought me
   on and I had no knowledge of coreboot... let that sink in for a minute:
   people able and willing to do that work are so rare that they had to train
   one from scratch!
   - The reason there is no coreboot port for the original Broadwell-based
   Librem 15 yet is because the most logical approach was to finalize the
   initial work that had been done on the Librem 13 as per Ron's suggestion
   (making the learning curve a bit less steep by not having to start from
   scratch), and then to prioritize work towards the upcoming hardware so
   Purism can attempt to have it ready in time for it to be factory-preloaded
   instead of causing additional trouble for future users. The original Librem
   15 is still going to be ported, but I can't do everything at the same time,
   so things have to be prioritized. After the initial learning curve, I am
   now jumping into the deep end of the coreboot pool by porting a new board
   from scratch, so that's definitely an interesting challenge.
   - The reason we want to prioritize the ME vs. the FSP, is because a lot
   more people were interested in getting rid of the ME, so it is a higher
   priority, but the FSP is also going to be reversed eventually and coreboot
   deblobbed entirely.
   - Purism is trying to do the right thing and trying to defend privacy
   and security the best way it can (it even became a Social Purpose
   Corporation to protect that goal)... but instead of saying "You are
   mistaken on this and that, let me enlighten you and help you", you are
   instead bashing and trying to drive it into the ground because, for some
   reason unknown to me, you feel personally slighted by Purism's legitimate
   mistakes? How is that going to help protect people as a whole? It takes
   time to do things right, and being stuck in the past does not help things
   move forward. Give it a chance!
   - What did you see on the website making wrong claims? Let me know and I
   will pass on the message to get it fixed. The info on it is a *lot* more
   accurate than it was a few months ago, and pretty much any coreboot/ME
   claim has clear "work-in-progress" disclaimers along with it (without
   writing a huge wall of text on every page). Give me specifics and I'll
   forward the information to be corrected. I know there is a best effort to
   rectify mistakes and make things clear and unambiguous, if something
   remains unclear it's certainly just an oversight, not malice.


Thanks for reading,
Youness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170502/5674c02f/attachment.html>


More information about the coreboot mailing list