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

41–50 of 96 posts

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

#41

Post by mynameisbahaa »

chmaynard wrote: post #12
Cyph0n wrote: post #4

There is a great comment linked at the bottom of the article that explains what exactly caused the authentication bug (it was strncmp!). Is there somehow a law that states that the higher the severity of a software bug, the simpler the reason behind it?

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)

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

#42

Post by qb45 »

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.

They use ARC architecture and some embedded JVM. Of course this doesn't guarantee that the AMT web server runs on this JVM.

Few years ago somebody published analysis of the ME firmware for servers (desktop version was compressed with unknown algorithm). I'm sure you can google this for details.

> the fact that the issue was with strncmp

But we don't know for sure if it was strncmp. It's a logic bug, which can be implemented in any language. But again, maybe this server runs outside JVM and is written in C.

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

#43

Post by qb45 »

benchaney wrote: post #36
qb45 wrote: post #32

Earlier quoted context omitted.

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

It has to be MD5. They use HTTP digest auth, which uses MD5. You send a nonce, the browser throws a popup asking for password and returns md5(nonce+pass). No way around it.

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

#44

Post by stevenh »

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…

Hello fellow ordinary person using an account created a year ago and finally posting today for the very first time with comically irrational outrage over the possibility of people ever moving away from md5sum thus rendering useless whatever subset of shady tools you or your employer has that we don't know about yet. Consider making innocuous comments in various threads for a few weeks before you switch to psyop mode next time.

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

#45

Post by pritambaral »

kogepathic wrote: post #38
dom0 wrote: post #27

Earlier quoted context omitted.

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…

> ring -2 mode

ME runs below the SMM. So ring -3 or lower.

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

#46

Post by qb45 »

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?

Because occasionally you use wrong length with wrong pointer and read or overwrite something you didn't want to.

It's more convenient and safer to have these two variables packed together as a "string object" and have string functions operate on that - then they always know where the string starts and ends in memory.

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

#47

Post by qb45 »

pritambaral wrote: post #45
kogepathic wrote: post #38

Earlier quoted context omitted.

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

> ring -2 mode ME runs below the SMM. So ring -3 or lower.

ME is a separate processor, not a "ring" on the x86.

All this talk about "privilege level above normal software" and "ring -7" just muddies the water. It simply is a physically separate core running its own software which has access to all RAM and all PCIe devices and can program the Intel NIC to silently redirect selected packets away from the x86 cores to itself.

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

#48

Post by ComodoHacker »

Cyph0n wrote: post #4

There is a great comment linked at the bottom of the article that explains what exactly caused the authentication bug (it was strncmp!). Is there somehow a law that states that the higher the severity of a software bug, the simpler the reason behind it?

That comment id great, but where is the source? I can't find any technical details following links in the article. Moreover, Embedi team who found the vulnerability says[0] on their site: "Intel representatives have asked Embedi to hold off on disclosing any technical details regarding this issue until further notice."

Or is the commenter just guessing?

0. https://www.embedi.com/news/mythbusters-cve-2017-5689

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

#50

Post by rfugger »

benchaney wrote: post #9

I wish that this security incident would get more attention. It seems fundamentally unfair that some projects that are essentially volunteer labor get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets mostly ignored.

Being an advertiser has its privileges.
Post reply on HN