Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought' (arstechnica.com)

An anonymous reader quotes Ars Technica: A remote hijacking flaw that lurked in Intel chips for seven years was more severe than many people imagined, because it allowed hackers to remotely gain administrative control over huge fleets of computers without entering a password. This is according to technical analyses published Friday... AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all...

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote. "We had discovered a complete bypass of the authentication scheme." A separate technical analysis from Embedi, the security firm Intel credited with first disclosing the vulnerability, arrived at the same conclusion... Making matters worse, unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware... The packets bypass the OS completely.
The article adds that Intel officials "said they expect PC makers to release a patch next week." And in the meantime? "Intel is urging customers to download and run this discovery tool to diagnose potentially vulnerable computers."

Saturday Ars Technica found more than 8,500 systems with an AMT interface exposed to the internet using the Shodan search engine -- over 2,000 in the United States -- adding that "many others may be accessible via organizational networks."

Comments

Re:Ars story highest voted comment

[140Mandak262Jamuna]

strcmp() has its own vulnerability. By sending a string without the terminating '\0' you make the strcmp() function read past the buffer. So the right thing to do is switch the arguments around, so that the length is computed from a known valid string, not from the untrustworthy response string.

strncmp(response , computed_hash, strlen(computed_hash)) would be good. Or, hardwired a lower limit to avoid comparing strings less than 32 bytes.

Re:Predictable outcome

[Dogtanian]

Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.

Coincidentally, around six weeks back, I bookmarked this article, originally written in 2016. Notably, it says that:-

Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.

Pedantry; it doesn't appear to be on every Intel chip, only those with vPro enabled(?) Still a horrible idea.

Re: Dear Intel

[mikael]

This is what all backdoors look like. "Ooops, we accidently encrypt and decrypt the password and write it out at the end of the file". "Whoops, we missed out a break statement in the selection of the encryption algorithm, it always defaults to the legacy easily broken encryption method". "Oh, shooot, we forget to add the menu option to the router to filter out multicasts, anyone can send a SSDP multicast to that address and get a list of hosts returned."

Like Microsoft's Windows OS firewall doesn't allow blocking of Microsoft telemetry servers. Wonder why? What could be so harmful in blocking a data stream of a few hundred bytes/second?

Lack of negative testing - extremely common

[raymorris]

This much more common mistake than one might think. A *lot* of applications will accept an empty password. It's one of the more common of the 90,000 or so vulnerabilities that we test for.

Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative - what does it do with incorrect input? If a program retrieves a web page, what if it's empty? What does a searching or sorting program do when asked to aort or search an empty list, or a list of just one item? That stuff doesn't get tested much.

Discovery tool only Windows

[OFnow]

The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?

Re:Predictable outcome

[Anonymous Coward]

Intel Management Engine doesn't work like that. It's not something that gets applied in the UEFI or BIOS firmware. It's a completely separate processor running a proprietary and trade-secret operating system with control over much of the system resources alongside the x86 boot chain. This is specifically for security reasons: Intel ME is sold as a remote-control solution for businesses that need to maintain control over their computers even if the x86-side boot chain has already been compromised by malware.

Oh and AMD did the same thing - AMD CPUs from 2013 onward include a PSP or Platform Security Processor whose source is closed and is a black box anyway. It will hold the x86 cores in RESET until it can find a valid and cryptographically-signed firmware blob to run. Oh, and both the AMD PSP and the Intel ME implement code-signing for the x86-side firmware, which specifically prevents Libreboot from working on those platforms. CPU manufacturers do not want anyone other than licensed-and-bonded motherboard manufacturers from writing firmware code.

Computer manufacturers let you disable AMT

[ayesnymous]

When I was looking at buying a Dell or HP laptop a couple years ago, they both gave me the choice of disabling vPro. AMT is a subset of vPro. So you could disable it if you wanted. Not sure why anyone would choose to have it enabled. And from what I've read, if you have them disable vPro at the factory, it's not possible to enable it later.

Re:I don't think you know what that word means.

[smallfries]

You know that Intel processors without AMT still have the capability but it is disabled in software...