Slashdot Mirror
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."
"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."
"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.
He and I have different definitions for the word "worked".
It must have been something you assimilated. . . .
Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.
(What? I get that security is hard and that sometimes there are unforeseen vulnerabilities. But... you can enter any text as the password, and it accepts it? Did no one at Intel test a wrong password at any point? This isn't a bug, this is outright negligence.)
The article is a bit confusing regarding this, but no, you can't send an empty password. That's because when a browser does digest authentication it doesn't actually send the password, or even a password hash, to the web server.
The browser sends instead a response MD5 hash computed on a string composed of various items, including a variable nonce sent by the server, in addition to the password, for example:
response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI)) ... entication
https://en.wikipedia.org/wiki/Digest_ac
This means a normal browser would never send an empty response, even when you enter an empty password. It would always send a 32 hex digit MD5 hash looking like this:
response="6629fae49393a05397450978507c4ef1"
The server would then compute the same hash, and compare them. If they are equal, it allows login, if they are different it denies login.
The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:
strncmp(string1, string2, N)
http://www.cplusplus.com/reference/cstring/strncmp/
And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:
strncmp(computed_hash, response, strlen(response))
So when it compared a real hash generated by a browser it would do something like:
strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d", 32)
This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn't match, and it would reject the empty password or invalid password.
So anyone testing this from a browser would find it works perfectly.
The problem is what happens if you don't use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this:
strncmp("6629fae49393a05397450978507c4ef1","",0)
This means the function will compare the first 0 characters between the two strings. So it is equivalent to:
strncmp("","",0)
Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal.
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 and you don't need to supply a length parameter, like this:
strcmp(string1, string2)
http://www.cplusplus.com/reference/cstring/strcmp/
When companies will bear responsibility for flaws in such features, as AMT encrypted and obfuscated from 3rd party analysis and management, and enabled by default, and for such screw ups they will pay hefty fines, they will think twice, before making features work such way.
see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed
Moneyquote:
But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?
Russian and Chinese government agencies have been passively or actively promoting the development of a domestic semiconductor industry.
It is time to finally star holding engineers criminally and civilly liable, ...
Force them to chose between risking jail for a bug or being fired for not following the Pointy Haired Boss' instructions to skip the tetsting and get the damn thing delivered?
What a great idea. Put most of the engineers who would actually do what you want out of work and leave the field to those to dumb to notice or too psychopathic to care.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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?
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
No, Intel AMT runs completely independently of the operating system. It doesn't matter whether the operating system is Windows, Linux, BSD, or anything else.
In fact, it's even worse. Intel AMT can still be running while the computer is off (but still plugged in). See
https://fsf.org/blogs/community/active-management-technology
Let me say it again: your computer can be pwned while it's off! You don't need to have anything running at all, because Intel AMT keeps running in the background as long as the machine is plugged in.
" 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..."
I find it hard, very very hard, to believe that this was an accident or just the result of stupid coding. This was either deliberate or was some carefully planned subversion somewhere along the tool chain.
Just cruising through this digital world at 33 1/3 rpm...
However, if you aren't going to buy anything that has had a remote code exec vuln, you should probably consider using pen and paper, exclusively!
Uh, a computer with no OS installed should never have a vulnerability. Ever.
It's not a hard thing to do, there are plenty of models that have succeeded, even from crappy companies like Compaq.
If you're going to release something that allows hackers to have ultimate, undetectable control over the computer, you better give it a security audit. All indications are that Intel does not have proper security processes for their systems. This is just one example.
"First they came for the slanderers and i said nothing."
Now one wonders what great "security features" Intel has places in their network cards, chipsets and CPUs. This really is on the most stupid level possible. They cannot even have done an internal review of this code that deserves the name before putting it into production.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The employers aren't currently held responsible either.
The problem is that the developers have no power over management to make them do the right thing. Unless and until they do, it isn't reasonable to hold them responsible. They can't make their employer do QA tests, they can't make the employer push the schedule back, and they can't prevent the premature release of a product.
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.
and
So a remote exploit could just consist of power cycling to boot from a external boot image. Only OS requests are sent to the OS, everything else is supposed to be caught at the hardware level.
We succumb to the overlords when we use proprietary software!
The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?
The Intel-recommended "mitigation" until the patch is released involves "Unprovisioning clients". What the ___ does that mean? They provide software to do it, but what exactly are the effects? (And yes, I did a web search, but it was unenlightening.) There is a wikipedia article here
https://en.wikipedia.org/wiki/...
on "provisioning", but it talks about seven different kinds of provisioning, and it's not clear which one the Intel doc is talking about. Nor is it clear from reading that article what the effects of UNprovisioning would be. Loss of ability to go on the web? Inability to download antivirus updates? Is it reversible, when the fix from Intel comes out? (and if a computer is "unprovisioned", can you even get the fix from Intel when it comes out?)
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.