Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

81–90 of 96 posts

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

#81

Post by jjnoakes »

mynameisbahaa wrote: post #41
chmaynard wrote: post #12

Earlier quoted context omitted.

From the comment: 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...

I think the programmer should have supplied the length of the "computed_hash" not the "response" which as I understood supplied by the user. Like this : strncmp(computed_hash, response, computed_hash_length)

You don't want to use strncmp() for this; aside from the timing attacks it opens up, using strncmp() for these kinds of comparisons implies that the operation you are performing is "string a is a prefix of string b" (or vice-versa).

Even though your example ends up being ok-ish (if the computed hash is a prefix of the response, perhaps it is ok to ignore any trailing junk in the response), intent is important for code quality and maintainability.

In this instance, the operation desired is "string a matches string b", which means strcmp() would be the right solution (ignoring timing attacks).

Of course, since we're talking about sensitive crypto operations here, neither is really the right answer. But in non-crypto contexts, if you want to know if two (valid) strings are the same, just use strcmp().

The "n" and the length argument doesn't automatically make strncmp() "safer" somehow; it is a totally different operation.

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

#82

Post by jjnoakes »

tyingq wrote: post #67
ComodoHacker wrote: post #49

So where all this authentication and web UI code resides? Is it in the BIOS? Is there somewhere a packed JQuery or something?

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, though, they should be using a strcmp()-like routine that works in a content-independent timing fashion.

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

#83

Post by angry_octet »

mynameisbahaa wrote: post #41
chmaynard wrote: post #12

Earlier quoted context omitted.

From the comment: 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...

I think the programmer should have supplied the length of the "computed_hash" not the "response" which as I understood supplied by the user. Like this : strncmp(computed_hash, response, computed_hash_length)

Yes. It was hilarious that the poster thought strcmp was the solution...

Though perhaps memcmp with fixed size buffers would be better still, no worrying about null terminated strings.

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

#84

Post by jjnoakes »

geofft wrote: post #10

At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function. If you want to fix this, there's no strict need to move away fro…

> At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software?

In general I agree, we have a long way to go to writing more secure software by default.

But this specific issue is different. The issue was not the string length was incorrect (the length passed to strncmp was the correct length for the response string); the problem here was a logic problem, which is harder to get right just by switching string implementations.

The buggy code in question was basically (in an imaginary language with fully managed strings):

    if response is_a_prefix_of expected_hash:
      allow_login()
when it should have been

    if response is_equal_to expected_hash:
      allow_login()

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

#85

Post by geofft »

code_sloth wrote: post #13
geofft wrote: post #10

At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function. If you want to fix this, there's no strict need to move away fro…

Could you elaborate on why "treating the pointer to a string and the string length as separate vars" is dangerous to someone who hasn't done a lot of C?

Basically, it encourages you to store only the string pointer and re-calculate the length (or let a library function do so) or use the wrong length value, which means if there's some specific length or capacity worth paying attention to, it's easy to get it wrong.

Really you want both a length, of the data actually in the string, and a capacity, marking how much memory is valid.

If I'm understanding the vulnerability right: strncmp takes three arguments, the beginning of the first string, the beginning of the second string, and the maximum number of bytes to compare. That maximum isn't quite a length or a capacity. It's a bound on the length, if one of the strings isn't null-terminated. But if you provide too small a maximum, it'll only compare the first few characters, and return a value based on that.

In particular they compared the target string to the user-provided string, with a user-provided length, so if you provide an empty string, it compares 0 bytes and returns success.

An API of the form strcmp(struct actual_string a, struct actual_string b) wouldn't have this problem - the actual string structures (instead of a char pointer) would provide a length for both strings, so the API wouldn't let you make this sort of error.

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

#86

Post by geofft »

jjnoakes wrote: post #84
geofft wrote: post #10

At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function. If you want to fix this, there's no strict need to move away fro…

> At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? In general I agree, we have a long way to go to writing more secure software by default. But this specific issue is different. The issue was not the string length was incorrect (the lengt…

Yeah, but if you are writing that pseudocode, it's obvious that is_a_prefix_of is the wrong operation.

The problem is that strncmp is in fact a prefix-comparison function when used with n calculated one way, but also it's the "safer" version of strcmp when used with n calculated another way, and it's easy to confuse the two uses.

In any other string implementation, you'd just use the most obviously-named compare function, there would be no need for a "safer" version of that function (there'd just be one reasonable comparison function), and it would do the right thing.

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

#87

Post by theophrastus »

tyingq wrote: post #76
lima wrote: post #21

I disagree with the article. If anything, it's much less severe than many people thought. - It's a logic bug (authentication bypass) instead of a memory corruption. An authentication bypass is bad, but a full compromise would have been much worse. - It's a bug in the opt-in AMT management, which means that the default config is not vulnerable.

> "much less severe than many people thought" I don't think so. There's a second bug that allows local non-privileged users to provision AMT. And, once it's up and running, you have a full remote KVM where you can boot recovery disks, edit the local files then reboot, etc. Having AMT on isn't that unusual either. It's not the default, but lots of people use it. I know some digital signage units using NUCS have it on,…

"Having AMT on isn't that unusual either. It's not the default"

AMT is on by default in at least a number of the popular thinkpad series[1] (i'm the only owner of a relatively old thinkpad, and only because of this security alert i checked and it was on; never haven't turned it on myself)

[1] https://forums.lenovo.com/t5/Security-Malware/Intel-AMT-back...

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

#88

Post by benchaney »

megadollar wrote: post #17
lisper wrote: post #2

It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.

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 addition, you are completely wrong about the harm caused by simplifying the rules of thumb for security. There is not good reason to ever use MD5 for this purpose, and saying "MD5 is ok in some cases" has the potentially to do far more harm than "never use MD5".

> note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)

Don't act like you are doing GP a favor, second preimage is the attack that would cause a vulnerability in this usage of MD5.

You are the one who is"opin[ing] on security threads while not quite understanding anything", so I think before the next time you condescendingly correct someone you should make sure you have a basic understanding of what you are talking about.

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

#89

Post by jjnoakes »

geofft wrote: post #86
jjnoakes wrote: post #84

Earlier quoted context omitted.

> At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? In general I agree, we have a long way to go to writing more secure software by default. But this specific issue is different. The issue was not the string length was incorrect (the lengt…

Yeah, but if you are writing that pseudocode, it's obvious that is_a_prefix_of is the wrong operation. The problem is that strncmp is in fact a prefix-comparison function when used with n calculated one way, but also it's the "safer" version of strcmp when used with n calculated another way, and it's easy to confuse the two uses. In any other string implementation, you'd just use the most obviously-named compare func…

> 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 than using strcmp() when you want equality (as this Intel issue shows) because it is easy to forget the length check. strcmp() does it implicitly for you.

I agree the names are not ideal (in fact I write my own streq() and strpfx() routines because I think it reads easier and it is also easy to get the return value of strcmp() wrong), but again, that has nothing to do with separating the string's pointer and its length.

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

#90

Post by geofft »

jjnoakes wrote: post #89
geofft wrote: post #86

Earlier quoted context omitted.

Yeah, but if you are writing that pseudocode, it's obvious that is_a_prefix_of is the wrong operation. The problem is that strncmp is in fact a prefix-comparison function when used with n calculated one way, but also it's the "safer" version of strcmp when used with n calculated another way, and it's easy to confuse the two uses. In any other string implementation, you'd just use the most obviously-named compare func…

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

Post reply on HN