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

31–40 of 96 posts

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

#31

Post by benchaney »

dom0 wrote: post #29
benchaney wrote: post #15

Earlier quoted context omitted.

strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is…

Yep, even if they had used memcmp/strncmp correctly the AMT would still be vulnerable to a timing attack here, which is probably even easy, because it runs on a low-power system with, I assume, not much background activity.

In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.

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

#32

Post by qb45 »

benchaney wrote: post #15
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...

strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is…

> Also, fixed length hashes aren't strings.

In HTTP everything is a string.

> Using a proper cryptography library also might have saved them from using MD5.

HTTP, again. Browser sends MD5 whether you like it or not.

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

#33

Post by Kubuxu »

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…

strncmp and other API that treats the pointer to the string and its length as separable variables are not dangerous. They are much more secure than the non 'n' options.

With them you don't have to worry about lack of null termination as the n determines the length of the string.

Problem here was usage of them at all. Hashes are not really strings, memcmp should have been used or even better secure (that doesn't leek timings) memcmp should be used.

Problem here was just mistake in the program not in the C lib.

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

#34

Post by qb45 »

benchaney wrote: post #31
dom0 wrote: post #29

Earlier quoted context omitted.

Yep, even if they had used memcmp/strncmp correctly the AMT would still be vulnerable to a timing attack here, which is probably even easy, because it runs on a low-power system with, I assume, not much background activity.

In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.

The attacker supplies ""-enclosed string and the HTTP parser is supposed to verify this.

Maybe they used some in-place HTTP parser and that's why they didn't have zero-termination to use strcmp.

And btw, it's not clear if the code was C to begin with. I believe large chunk of ME firmware is said to be written in Java, which kinda makes sense for a network facing system considering how shitty string.h is.

It would be interesting if somebody found that they are using some COTS webserver, C/Java - doesn't matter, and see if there are some CVEs for it.

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

#35

Post by qb45 »

lightedman wrote: post #24
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.

"An authentication bypass is bad, but a full compromise would have been much worse." Given the authentication bypass essentially leads to full compromise, where's the difference, here?

The difference is, you are no longer limited to functionality normally provided by AMT. Maybe AMT doesn't offer the ability to download arbitrary memory locations from the running OS and applications, with remote code execution on the ME you could do that. You could modify code running on the CPU on-the-fly and make it read files from disk to memory for downloading too - again, I don't think AMT can read disks, especially when the OS is running and using them concurrently.

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

#36

Post by benchaney »

qb45 wrote: post #32
benchaney wrote: post #15

Earlier quoted context omitted.

strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is…

> Also, fixed length hashes aren't strings. In HTTP everything is a string. > Using a proper cryptography library also might have saved them from using MD5. HTTP, again. Browser sends MD5 whether you like it or not.

> In HTTP everything is a string.

Once you parse it out of HTTP it is no longer as string (or at least it should no longer be a string).

>HTTP, again. Browser sends MD5 whether you like it or not.

They are quite clearly doing verification themselves. They can use whatever algorithm they want.

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

#37

Post by benchaney »

qb45 wrote: post #34
benchaney wrote: post #31

Earlier quoted context omitted.

In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.

The attacker supplies ""-enclosed string and the HTTP parser is supposed to verify this. Maybe they used some in-place HTTP parser and that's why they didn't have zero-termination to use strcmp. And btw, it's not clear if the code was C to begin with. I believe large chunk of ME firmware is said to be written in Java, which kinda makes sense for a network facing system considering how shitty string.h is. It would be…

I doubt using Java would really help in this case, because in order to use Java they would have to port the entire JVM to whatever platform they are using. Doing this without introducing any security bugs is about as difficult as just doing everything in C to begin with. By the way, the fact that the issue was with strncmp very strongly suggests that the issue was in C code.

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

#38

Post by kogepathic »

dom0 wrote: post #27
lightedman wrote: post #24

Earlier quoted context omitted.

"An authentication bypass is bad, but a full compromise would have been much worse." Given the authentication bypass essentially leads to full compromise, where's the difference, here?

The ME itself is not compromised. Arbitrary code execution on the ME would mean total control of the host, i.e. privileges above any software you can run on a computer.

> would mean total control of the host, i.e. privileges above any software you can run on a computer.

You don't need arbitrary code execution, the ME already has privileges above any software you can run on the computer. The ME operates in ring -2 mode [0], whereas the OS kernel has at most ring 0 privileges.

With the built-in ME functionality you can: reboot the host, change BIOS settings, re-install the OS, update BIOS (boot FreeDOS & run the vendor utility).

Couple this with a vendor vulnerability such as not signing and verifying a BIOS before flashing, and you can easily use the ME to flash a BIOS with malicious components to the computer.

So, yes, it's not as bad as using the ME to read arbitrary memory regions while the host is on, but the default ME functionality for remote management is still enough for a malicious actor to cause a lot of harm.

[0] https://en.wikipedia.org/wiki/System_Management_Mode

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

#39

Post by rusanu »

benchaney wrote: post #15
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...

strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is…

They were implementing HTTP Digest[0]. This leaves no room to choose something other than MD5. And I'm not sure what other HTTP authentication scheme they could had chose for firmware (ie. cannot take dependency on anything in infrastructure, like PKI or Kerb)

[0] https://en.wikipedia.org/wiki/Digest_access_authentication

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

#40

Post by dom0 »

benchaney wrote: post #37
qb45 wrote: post #34

Earlier quoted context omitted.

The attacker supplies ""-enclosed string and the HTTP parser is supposed to verify this. Maybe they used some in-place HTTP parser and that's why they didn't have zero-termination to use strcmp. And btw, it's not clear if the code was C to begin with. I believe large chunk of ME firmware is said to be written in Java, which kinda makes sense for a network facing system considering how shitty string.h is. It would be…

I doubt using Java would really help in this case, because in order to use Java they would have to port the entire JVM to whatever platform they are using. Doing this without introducing any security bugs is about as difficult as just doing everything in C to begin with. By the way, the fact that the issue was with strncmp very strongly suggests that the issue was in C code.

Some security paper showed ARM disassembly of the issue, although I'm not sure if that was this specific issue or just another "strncmp-induced" issue.

(Btw. there are many smaller Java VMs for stuff like Java Card and JEFF)

Post reply on HN