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

Wed May 10 11:06:22 CEST 2017

Let me demystify this bug. It is so trivial, at the end of the day, I will
ask some questions here, openly on the list!?

It is, after all, most of 13K Front Line Managers in INTEL with reputations
on stake for this bug, with really questionable (minimum required)
qualities, as well as technical, as well as human/personal characteristics!

It is just that some INTEL junior programmer was so thrilled about C lib
recent acquired knowledge, that (s)he, by unconscious mistake, used f-n
strncmp() instead much safer strcmp()???

What about INTEL testing teams? INTEL QA teams?!

Zoran Stojsavljevic
_______

   - MemberBerry
   <https://arstechnica.com/civis/memberlist.php?mode=viewprofile&u=565983>
Wise,
   Aged Ars Veteran
   - The article is a bit confusing regarding this, but no, you can't send
   an empty password. That's because when a browser does digest authentication
   it doesn't actually send the password, or even a password hash, to the web
   server.

   The browser sends instead a response MD5 hash computed on a string
   composed of various items, including a variable nonce sent by the server,
   in addition to the password, for example:

   response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI))
   https://en.wikipedia.org/wiki/Digest_ac ... entication
   <https://en.wikipedia.org/wiki/Digest_access_authentication>

   This means a normal browser would never send an empty response, even
   when you enter an empty password. It would always send a 32 hex digit MD5
   hash looking like this:

   response="6629fae49393a05397450978507c4ef1"

   The server would then compute the same hash, and compare them. If they
   are equal, it allows login, if they are different it denies login.

   The bug was in the code to compare the two strings. It used the strncmp
   function that compares the first N characters of two strings:

   strncmp(string1, string2, N)
   http://www.cplusplus.com/reference/cstring/strncmp/

   And applied it to the computed hash and the hash response received from
   the browser, with N set to the length of the response received from the
   browser, so something like:

   strncmp(computed_hash, response, strlen(response))

   So when it compared a real hash generated by a browser it would do
   something like:

   strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d",
   32)

   This would work just fine for hashes sent by the browser, which are
   always 32 characters in length. Even if the password field is empty, it
   would compare the two strings, they wouldn't match, and it would reject the
   empty password or invalid password.

   So anyone testing this from a browser would find it works perfectly.

   The problem is what happens if you don't use a browser, but you generate
   an invalid request manually or using a proxy to alter the response, sending
   an empty string instead of the 32 character hash. Then the compare code
   does this:

   strncmp("6629fae49393a05397450978507c4ef1","",0)

   This means the function will compare the first 0 characters between the
   two strings. So it is equivalent to:

   strncmp("","",0)

   Of course, two 0 length strings are equal, so it wrongfully concludes
   the hashes are equal.

   What the programmer should have done is check if the hash coming from
   the browser has the correct length, 32 characters, before attempting to
   compare the two strings.

   Or even better, the programmer should have used the proper string
   comparing function, strcmp, that already does that for you and you don't
   need to supply a length parameter, like this:

   strcmp(string1, string2)
   http://www.cplusplus.com/reference/cstring/strcmp/

On Mon, May 8, 2017 at 8:32 PM, Rene Shuster <rene.shuster at bcsemail.org>
wrote:

> In case you missed it: https://www.tenable.com/blog/
> rediscovering-the-intel-amt-vulnerability
>
> On Fri, May 5, 2017 at 8:10 AM, Peter Stuge <peter at stuge.se> wrote:
>
>> First, thanks to everyone who is working hard to maintain a good tone
>> on the list. I certainly appreciate that.
>>
>> While the ME and that it may have issues ;) is not so big news for many
>> in this community, this is an important news story for IT in general,
>> as it furthers the goal of platform and firmware openness.
>>
>>
>> Sometimes I disagree strongly with Ron, but I think he makes a good
>> point here:
>>
>> ron minnich wrote:
>> > I realize feelings are strong about these issues, but calling
>> > people and projects "corrupt" is unacceptable and, in my view
>> > anyway, I'd like people who say such things to find another
>> > project.  I watched the Plan 9 mailling list get destroyed by a few
>> > bad actors and I don't want to see that happen here.
>>
>> I don't think saying "corrupt" is neccessarily taboo, but the word
>> needs to be used carefully, or you may just end up poisoning the
>> community - *that* is unacceptable.
>>
>> I would like to take this opportunity to ask a favor of everyone
>> in this community: Don't allow words to poison you too easily. Stay
>> strong. I found this graphic very helpful:
>>
>> http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of
>> -debate-550x417.jpg
>>
>> Don't fall down the pyramid, and don't let anyone else pull you down.
>>
>>
>> It's easy to claim that someone else does the wrong<tm> thing even
>> with good intentions, but you can extrapolate that someone is doing
>> wrong<tm>, just because they seem to have good intentions.
>>
>> And keep in mind that while everyone in the coreboot community seeks
>> open firmware more or less actively, some seek even more open platforms
>> than others.
>>
>> As long as someone is investing in improving the firmware status quo,
>> that is a good thing for all of us, even if the road becomes somewhat
>> longer than we may like. It's not for me to say what someone else
>> spends their time developing. I can disagree, and tell them, as they
>> can with me, but I can't expect them to care.
>>
>>
>> My personal attitude to Librem as far as an open laptop platform goes
>> is that it's too little too late, but that that's not really through
>> any fault of Puri.sm.
>>
>> Sure, I was disappointed by early communication with the company about
>> the difficulties of the task they had set for themselves, and I agree
>> that they have been underestimating the problem. I am guilty of that
>> too at times. The question is what we do to better ourselves.
>>
>> Like Ron, I think it's great that Youness is joining the coreboot
>> community! :)
>>
>>
>> //Peter
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign <http://comicsanscriminal.com>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170510/fa91ff98/attachment.html>