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

71–80 of 96 posts

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

#71

Post by tyingq »

qb45 wrote: post #35
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 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, espec…

You can boot a recovery image though, and edit files on the installed OS that way.

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

#72

Post by tyingq »

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.

AMT offers basically IPMI though. Boot a recovery image over the net, mount the local drive, and edit away.

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

#73

Post by chillingeffect »

coldtea wrote: post #61
stevenh wrote: post #44

Earlier quoted context omitted.

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…

Tin foil much? As if what will ...really help NSA and co are 1-2 random comments of technical pedantry regarding MD5 on an insignificant (in the grand scheme of things) forum people go to discuss the latest startup news, JS frameworks, the benefits of functional programming, Golang, tech industry developments, and some CS related news.

Sustained disinformation campaigns are a go-to strategy. Redirecting and confounding conversations are documented tactics. They don't even have to be particularly well veiled or surgically placed as their value derives from their volume.

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

#74

Post by chillingeffect »

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

It almost smells like an obfuscated tactic to evade review. In a rush a reviewer might see strncmp and think "Not using strcmp. Check." without going all the way to consider the strlen as argument, which really should have been a constant and the smoking gun.

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

#75

Post by tyingq »

There's two things that don't get mentioned much with this issue.

1. There's a second bug that allows non-root local users to provision AMT. "An unprivileged local attacker could provision manageability features"[1]

2. Access to AMT allows you to boot a recovery image, mount local drives, and do whatever you like with the included remote KVM.[2][3]

So, even if this is turned off, there are issues to address. If it's on, they have control of the whole machine, remotely. It's as bad as it can get.

[1] https://security-center.intel.com/advisory.aspx?intelid=INTE...

[2] https://software.intel.com/en-us/node/681803

[3] https://software.intel.com/en-us/node/674998

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

#76

Post by tyingq »

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, for example. Also, some large company data centers use it instead of IPMI. The ports aren't exposed to the internet, but if hackers get inside a different way, they are off to the races.

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

#77

Post by mjw1007 »

One interesting note in the article: « unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware. »

That's unsurprising now I think about it, given how AMT works, but aren't the sort of companies that would want to use AMT also the sort of companies that have security policies that require all such things to be logged?

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

#78

Post by qb45 »

tyingq wrote: post #71
qb45 wrote: post #35

Earlier quoted context omitted.

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

You can boot a recovery image though, and edit files on the installed OS that way.

It just isn't quite as stealthy if you have to power up the box when it's supposed to be off.

I mean, not everybody runs Windows 10 and is used to his machine having a free will of its own ;)

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

#79

Post by rocqua »

Neliquat wrote: post #65
dataminded wrote: post #64

This is a dream come true for AMD.

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.

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

#80

Post by geofft »

Kubuxu wrote: post #33
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…

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

"More secure" doesn't imply "not dangerous". It's definitely safer to drive a car without seatbelts than to ride a bike down the highway, but that doesn't mean that not wearing your seatbelt isn't dangerous.

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

This is incorrect for two reasons.

The first is that hashes in ASCII format are strings: it's useful to want, for example, case-insensitive hash comparisons.

The second is that (if I'm understanding the vulnerability correctly) the exact same bug would be present with memcmp:

    if (memcmp(target, user_string, user_string_length) == 0)
> Problem here was just mistake in the program not in the C lib.

Yes. But a library that people make mistakes with all the time is dangerous. If you are a programmer who ever makes mistakes (and clearly the AMT folks are, but I'm pretty sure so is everyone), you should avoid dangerous libraries.

Post reply on HN