The hijacking flaw that lurked in Intel chips is worse than anyone thought • Hacker News Board

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#91

Post by adkafka » Sun, May 07, 2017, 11:16 PM UTC

jjnoakes wrote: post #82

tyingq wrote: post #67

Earlier quoted context omitted.

It's in the AMT code, written in C, in the management engine processor...which is separate from the main processor. See: https://software.intel.com/en-us/node/631399 They are using HTTP Digest Authentication, which is built into browsers. The purpose was to keep passwords from being clear text over regular http connections. So, the code on the client side is in the browser. The code on the server side is in the manag…

> The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. Ignoring timing attacks, they should have used strcmp(), not strncmp(). strncmp() is for testing if one string is a prefix of another; they wanted to test if some string equaled another. Since this is crypto related stuff, thoug…

But using strcmp could result in buffer overflow, no?

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#92

Post by jjnoakes » Mon, May 08, 2017, 12:19 AM UTC

adkafka wrote: post #91

jjnoakes wrote: post #82

Earlier quoted context omitted.

> The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. Ignoring timing attacks, they should have used strcmp(), not strncmp(). strncmp() is for testing if one string is a prefix of another; they wanted to test if some string equaled another. Since this is crypto related stuff, thoug…

But using strcmp could result in buffer overflow, no?

How so? We aren't talking about strcpy(), just strcmp(), and all the strings in question should be nul-terminated (if they aren't then mem* routines should be used and more length checks would be needed; there are also timing attacks to worry about if we're considering all the possible issues).

But normally strncmp isn't safer than strcmp. They just do different things.

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#93

Post by jjnoakes » Mon, May 08, 2017, 1:14 AM UTC

geofft wrote: post #90

jjnoakes wrote: post #89

Earlier quoted context omitted.

> also it's the "safer" version of strcmp when used with n calculated another way This isn't true; first off it isn't "safer" than strcmp() at all (this isn't strcpy vs strncpy after all), and second, no length argument to strncmp() will make it act like strcmp(). In order to get strcmp(), you have to also check the lengths are the same first. strlen(a) == strlen(b) && strncmp(a, b, strlen(either)) This is less safe…

I agree with you, but please argue with the other person who objected to my comment saying that strncmp was obviously the safer version of strcmp. :-) An API where experienced users don't even agree what the function is supposed to be is a bad API.

How do you know all parties involved in this discussion are experienced?

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#94

Post by megadollar » Mon, May 08, 2017, 3:26 AM UTC

benchaney wrote: post #88

megadollar wrote: post #17

Earlier quoted context omitted.

That's fine. I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. Take your attack vector to be that particular md5sum that you are making fun of. MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer securi…

The reason that people move away from a hash function when it looses collision resistance is that collision resistance serves as a measure of the security margin for preimage resistance. Cryptographic primitives are intended to be rotated out of use about 10-15 years before they become actually broken for their intended purpose. Unless you are willing to extend you bounty to the year 2030 it is means nothing. In addi…

You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb and you've since argued against a strawman. Did I ever say "MD5 is ok in some cases"?

Aside: a preimage attack implies a second preimage attack.

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#95

Post by Unklejoe » Mon, May 08, 2017, 12:43 PM UTC

rocqua wrote: post #79

Neliquat wrote: post #65

Earlier quoted context omitted.

AMD has a similar system, likely with simular issues. Their smaller footprint means they just take longer for people to notice than an Intel snafu. Hopefully this will give them a preemptive heads up to harden theirs before an exploit is discovered.

AMD made some noise (way before this vulnerability became known) about open-sourcing the code of their ME-equivalent and allowing people to flash their own code. That seems a lot better than Intel's stance on the ME.

Unless something new happened that I'm unaware of, it was more like "the people of Reddit made some noise in an AMA, and AMD basically said "we'll look in to it"".

Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought

#96

Post by benchaney » Mon, May 08, 2017, 10:30 PM UTC

megadollar wrote: post #94

benchaney wrote: post #88

Earlier quoted context omitted.

The reason that people move away from a hash function when it looses collision resistance is that collision resistance serves as a measure of the security margin for preimage resistance. Cryptographic primitives are intended to be rotated out of use about 10-15 years before they become actually broken for their intended purpose. Unless you are willing to extend you bounty to the year 2030 it is means nothing. In addi…

You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb and you've since argued against a strawman. Did I ever say "MD5 is ok in some cases"? Aside: a preimage attack implies a second preimage attack.

>You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb

Not all devs are security experts, or can even afford to focus on security. To deny the value of rules of thumb is to deny that they need to consider security.

> Did I ever say "MD5 is ok in some cases"?

Oh, really? Were you not arguing that MD5 is ok if you only need preimage resistance?

> MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security.

Hmm. Seems like you were...