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

    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@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@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@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

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot