SoylentNews is people
SoylentNews
Days after being announced, Tenable reverse engineered the Intel AMT Vulnerability. According to a blog post, the vulnerability is a backdoor dream. The AMT web interface uses HTTP Digest Authentication, which uses MD5. The problem is that partial matches of the hash are also accepted. Therefore, Tenable decided to experiment and while doing so:
[W]e reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header).
Authentication still worked. We had discovered a complete bypass of the authentication scheme.
Long story short, for over five years, a complete and trivial bypass of AMT authentication has existed. If this wasn't an intentional backdoor, it is a monumental mistake in security and coding best practices. Regardless, the "backdoor" is now public. With Shodan showing thousands of unpatchable computers (as no patch is currently available, assuming they would ever be patched) exposed to the Internet, some poor IT sod is bound to show up to work some bad news on Monday.
(Score: 3, Informative) by Anonymous Coward on Sunday May 07 2017, @11:26AM
...is right sometimes. [stallman.org]
(Score: 2) by Runaway1956 on Sunday May 07 2017, @11:39AM (2 children)
Some will assume this backdoor to be accidental. Then again - Intel built that chip that would identify itself online, every time it was connected to the internet. https://www.wired.com/1999/01/intel-on-privacy-whoops/ [wired.com]
For that and other reasons, I switched to AMD long ago, and have never looked back.
A MAN Just Won a Gold Medal for Punching a Woman in the Face
(Score: 1, Informative) by Anonymous Coward on Sunday May 07 2017, @01:26PM
AMD backdoor is better [reddit.com]
(Score: 3, Insightful) by Wootery on Monday May 08 2017, @08:32AM
It's part of a broader trend of 'smart' devices. Smart (hackable) cars, smart (hackable) lightbulbs, and even smart (hackable) CPUs.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @11:45AM (9 children)
as no patch is currently available, assuming they would ever be patched
I always assumed that this tech is mostly baked in hardware. Could this be patched?
(Score: 2) by Runaway1956 on Sunday May 07 2017, @11:56AM
Possibly, but maybe not. I like my AMD's, but early Sledgehammer chips had problems that required a microcode patch. Watching the bootup screen, that microcode patch was one of the first things to run during boot. Some info on one microcode update here: http://www.securiteam.com/securityreviews/5FP0M1PDFO.html [securiteam.com]
I guess you can patch a lot, but there is no indication in the article whether it can be patched. Some things are, as you say, "baked in".
A MAN Just Won a Gold Medal for Punching a Woman in the Face
(Score: 4, Informative) by zocalo on Sunday May 07 2017, @12:26PM (6 children)
I suspect we'll see the systemboard vendors do a *little* better than the phone vendors at supporting legacy hardware here, but going back the full decade seems incredibly unlikely, as does all the operators of vulnerable systems actually downloading and installing the new firmware on their own initiative. All in all, we're almost certainly going to have a lot of vulnerable systems sitting around until they get replaced with new hardware for whatever reason; probably another decade or so in some cases. What's also worth pointing out is that this isn't just the remote network attack (which is bad enough), there's also a local priviledge escalation attack that can be run from a malicious binary on a vulnerable PC, so we can expect to see a lot of PCs rooted with this once that starts getting exploited.
UNIX? They're not even circumcised! Savages!
(Score: 3, Informative) by frojack on Sunday May 07 2017, @10:40PM (5 children)
There is also a detection guide https://downloadcenter.intel.com/download/26755 [intel.com]
As well as a the mentioned mitigation tool (which seems pretty useless to me).
The problem is getting past the OEM's protection of the microcode. If that were easy there would be much larger problems.
These details of how to exploit this issue are now public. Those sitting behind a firewall (A SEPARATE physical firewall that is not itself vulnerable) really have only yourselves and your workmates to fear.
It involves a http operation to obscure port(s) 16992 AND 16993 (plus or minus a few depending on the sources you read). You also have to have provisioned the AMT before it is vulnerable, it does not normally come that way.
In a big company, I could see this being a huge problem, especially if you specifically bought these machines for this feature. So now you would have to firewall every one of them.
Apparently there are thousands of these sitting directly on the internet, probably in use as firewall/routers.
A somewhat less breathless discussion is here: https://mjg59.dreamwidth.org/48429.html [dreamwidth.org]
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by kaszz on Monday May 08 2017, @02:10AM (4 children)
The detection "guide" is a binary download for operating systems compatible with Microsoft windows 7 and 10. Maybe someone in the open source community will write a Unix equivalent that just reads in the BIOS data and evaluates it.
According to this page [intel.com], these processors are affected:
* Intel Core 2
* Intel Centrino 2
* Intel Core i5
* Intel Core i7
* Intel Centrino Processor
The same page describes checking AMT status by entering BIOS.
The OEM protection of the microcode has a solution:
* Neutralize ME firmware on Sandybridge and Ivybridge [github.io]
It might be the only way to be sure [youtube.com] ;-)
(Score: 1) by Scruffy Beard 2 on Monday May 08 2017, @02:19PM (3 children)
Thanks. I had missed the implications of the ME mention in the documentation for the BIOS update for my 965-based board. It is not like the manual explains what it actually does.
(Score: 2) by kaszz on Monday May 08 2017, @05:33PM (2 children)
Why did you want to update the BIOS ?
(Score: 1) by Scruffy Beard 2 on Monday May 08 2017, @05:45PM (1 child)
Hoping the latest update fixes any ACPI-related bugs? I think extra CPU support may have been included as well.
I know it falls into the "updates are always good" fallacy.
BIOS Update Release Notes (DG965 series -- Standard BIOS) [intel.com]
(Score: 2) by kaszz on Monday May 08 2017, @08:32PM
My thinking was kind of like. If you got an "old" BIOS. Maybe you could exploit to gain control of your machines hidden features?
ACPI seems to run in Intel Management (ring -2) mode so any BIOS update will also change this. But ACPI is notoriously bug ridden in implementation.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @09:55PM
A real hardware patch involves solder or more commonly a purchase.
(Score: 3, Funny) by kaszz on Sunday May 07 2017, @01:26PM (15 children)
Here's a really good explanation of the security hole:
Silent Bob is Silent [embedi.com]
Complete with assembler listing extracts, coupling to C code and how it all interacts. The core of it to have this in the 401 response:
"nonce=»qTILAAUFAAAjY7rDwLSmxFCq5EJ3pH/n», uri=»/index.htm», response=»»,". Take note on how the "response" parameter is empty. The next exhibit is:
if( strncmp(computed_response, user_response, response_length) )
exit(0x99);
If 'response_length' equals zero then.. ;-)
Btw, any idea on how to write ones own AMT or disable it on machines that will not get a vendor update?
Just waiting for that Intel Management Engine to also have a sufficient amount of "oops".
(Score: 2) by maxwell demon on Sunday May 07 2017, @01:52PM (14 children)
The irony in this is that strncmp is usually preferred over strcmp for security reasons. Yet if they had used strcmp here, the problem would not have occurred.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by kaszz on Sunday May 07 2017, @02:44PM (13 children)
strcmp() however will keep comparing until it reaches a NULL character, if it doesn't oops ensues..
So strncmp() is needed. But it's also needed to do some calculations on the length to compare. Ie the longest ones of the two strings but only to a certain max limit. And no shorter than a hard limit.
(Score: 4, Interesting) by maxwell demon on Sunday May 07 2017, @04:03PM (2 children)
If the strings are correctly generated inside the program (the null bytes are not coming from the input stream, after all), there will be a null byte terminating them. So the use of strncmp is a guard against incorrect generation of strings elsewhere in the program.
Anyway, if you have an implementation where strcmp always compares until a NUL character is found, then get a better implementation. Normally it only compares until either a NUL or a difference is obtained. So the most likely result of a bug here is that it claims a non-match if the strings would actually match, but lack a NUL termination (note that it suffices for one string to have the correct NUL termination in order to have strcmp stop).
And of course, in this case all possible results of missing NUL termination would have been better than the bug which this code resulted in:
Note that unlike e.g. strcpy, strcmp does not write to the memory occupied by (or, in the case of missing NUL termination, following) the strings.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by kaszz on Monday May 08 2017, @01:46AM (1 child)
So in essence they should have used strcmp(computed_response, received_response) and enforced proper null termination in the "computed_response" variable as that is one that can be thoroughly controlled. As for reading portions of memory "not belong to you". It can cause all kinds of nastiness, from segmentation, I/O trouble, endless loops or other triggers. Therefore at least I try to avoid that.
I can see two mistakes made by Intel:
0) Improper input control and that in a security password function.. doh!
1) Lack of testing corner cases, ie empty strings.
This lack of conscientious programming in security matters may be a strong indicator of serious bugs elsewhere. And the attacker only has to be right once while the defender has to be right at all times.
(Score: 2) by maxwell demon on Monday May 08 2017, @08:27AM
While the string content of received_response is received, its NUL termination is computed. That is, in a correctly written program it is impossible for an attacker to send text that results in a string in the program that's not properly zero-terminated.
Note that a correctly written program usually means extra workwhen using the strn function family: Since those may result in strings that are not zero terminated (IMHO a design defect of those functions), you always have to make sure that you manually add a zero termination that may be missing.
Of course you're supposed to avoid that. The point is that a bug that results in reading beyond the end of an allocated memory segment is much less likely to cause serious harm than writing beyond an end (and also less likely than reading from random memory locations), especially for something like strcmp which has an extremely high probability of terminating after reading just a few extra bytes.
And yes, you wouldn't want a segmentation fault or an "endless" loop, but I'd definitely prefer an occasionally crashing interface to an universal backdoor.
As for IO trouble, one would hope that there's no way to get to MMIO areas through buffer overruns without first producing a segmentation fault. But then, whoever decided on the memory layout might have been just as security conscious as the one who wrote the authentication code …
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by cafebabe on Sunday May 07 2017, @05:31PM (9 children)
strncmp() is given the length of the response. It should be given the length of the locally genderated hash. Never thrust the user.
1702845791×2
(Score: 3, Funny) by cafebabe on Sunday May 07 2017, @05:34PM (1 child)
Note to self: use another phone for tech stuff.
1702845791×2
(Score: 2) by Scruffy Beard 2 on Monday May 08 2017, @05:44AM
That is a known data leak [torproject.org].
(Score: 2) by pvanhoof on Sunday May 07 2017, @06:29PM (5 children)
What if parameters to functions could be annotated with something like const, but then instead of constness the origin. The strncmp function would then look like int strcmp(const internal *haystack, const external *needle, const internal length). A strlen would take the internal or externalness of the parameter and return it. Meaning that strncmp("test", var, strlen(var)) wouldn't compile for a external char* var, and would for a internal char* var. And it would compile for a strncmp("test", var, strlen("test")).
Just an idea ...
(Score: 3, Interesting) by cafebabe on Sunday May 07 2017, @07:54PM (3 children)
Ignoring the problems with mathematical functional notation, I think you understand the value of tainting and typing. Tainting is commonly used in some languages to prevent untrusted values being used without at least some superficial checks. Types are a much deeper problem best covered by some of the functional languages. Essentially, be aware of any generic string, integer, float, void pointer or VARCHAR(255). However, types need to be implemented at multiple levels, so, for example Burroughs mainframes [wikipedia.org] had a four bit type on each word of memory but would happily allow untyped integers in ALGOL.
There was quite a scary article explaining that the majority of string failures (excluding buffer overflows) were invariably due to concatenation of disparate string types. SQL injection? Cross site scripting? Invariably due to concatenation of mismatched string types. However, the article was pessimistic and stated that it would be difficult to prevent the problem re-occurring when programmers (who generally don't appreciate the issue) prefer languages which put brevity ahead of correctness. And, dammit, if you devise a language (compiled or interpreted) which perfectly enforces string types then how is that going to compete with Perl, Python, Ruby, JavaScript or any other language which copies the bad meme of a terse concatenate operator?
My extension to this is how far does that get you when taking into account Greenspun's tenth rule [wikipedia.org] ("Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.")? Nowhere. That's where.
If I've made you deeply uneasy about any integer or string that you or anyone else has ever defined then I have only partially conveyed my warning with sufficient emphasis because, in the long term, it will do very little to affect anyone's actions.
1702845791×2
(Score: 2) by Wootery on Tuesday May 09 2017, @10:12AM (2 children)
dammit, if you devise a language (compiled or interpreted) which perfectly enforces string types then how is that going to compete with Perl, Python, Ruby, JavaScript or any other language which copies the bad meme of a terse concatenate operator?
Depends on the problem domain, no?
Ada is a 'correctness-first' language, and has found a niche in critical-systems. Maybe they should try using something like Ada for this sort of code in future (where the cost of a bug is enormous) -- we all know C's track-record for 'low-level bugs'.
(Score: 2) by urza9814 on Tuesday May 09 2017, @11:17PM (1 child)
IS the cost of this bug enormous? I mean it could be to the company that gets screwed if it's exploited, but what does it really cost Intel? Nobody ever got fired for buying Intel, and I doubt anyone is seriously considering switching to AMD solely because of this bug. I don't think the cost to Intel is going to be much more than the cost of implementing the fix, which they can probably get nearly free by coercing a bunch of H1Bs to work a week of unpaid overtime. But using a correctness-first language would require them to allot more planned dev effort to the initial development, and it's harder to mandate overtime when it's not an "urgent production issue" so those hours will be more expensive because Intel will actually have to pay for them.
I wouldn't be surprised if coding this right in the first place was actually more expensive than fixing it later. That's why the problem exists in the first place. Intel ought to be sued into oblivion for gross negligence over shit like this (not for just having a bug, but for first designing such a massive security hole and then not bothering to even test a null login on such a critical system) but instead they'll hide behind the usual bogus clickwrap EULA or whatever the firmware equivalent is...and they'll keep raking in the profits while the rest of us are screwed with one flaw after another over and over again...
(Score: 2) by Wootery on Wednesday May 10 2017, @08:45AM
I disagree. I think this could cost them bigtime. Your CPU turning out to be hackable is the best thing you can do to scare off security-aware customers.
coercing a bunch of H1Bs to work a week of unpaid overtime
Intel's software engineers do not, on average, work for free. Let's not be silly.
I wouldn't be surprised if coding this right in the first place was actually more expensive than fixing it later.
But again, you're pretending there's no way this could scare off big customers. Military cyber-security folks might seriously question opting for Intel products in future, for instance. It says a lot about Intel that they allowed this to happen in the first place, both in terms of their competence and their high-level values and decision-making. They placed gimmicky bullshit over risking exposing their customers to below-ring-zero compromise.
I agree that a lawsuit deterrent isn't likely, but I don't agree that the market will necessarily forgive them.
(Score: 2) by TheRaven on Monday May 08 2017, @09:53AM
sudo mod me up
(Score: 2) by kaszz on Monday May 08 2017, @01:51AM
Rather, never trust the input to be what you expect.
(Score: 2) by The Mighty Buzzard on Sunday May 07 2017, @03:09PM (7 children)
Well, I suppose it could be. To each their own. I can come up with way better backdoor dreams though and nearly none of them would involve an Intel processor in any way.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @03:48PM (4 children)
That's because you aren't a true hacker.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @04:36PM (3 children)
He may have been referring to the booty.
In other news, can someone summarize the fallout of this on an affected machine? As in, does the system need to be powered on and does it allow for arbitrary code delivery and execution, or must the system be online and are the operations restricted to specific management-style activities?
(Score: 2) by choose another one on Sunday May 07 2017, @04:55PM
I think the target system needs to be powered on and online otherwise a consent exception is automatically generated - I could be wrong though, haven't tried.
Payload is likely to be arbitrary but limited in size by the target system, operations restricted but may be less so depending on how the target system is setup (is it constrained or restrained, never can remember...). Either way, operations outside of usual agreed parameters may required retreating to safe distance afterwards and/or engagement of lawyers.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @07:55PM
He may have been referring to the booty.
https://www.youtube.com/watch?v=xECUrlnXCqk [youtube.com]
(Score: 2) by The Mighty Buzzard on Monday May 08 2017, @01:53AM
If your system is powered on and vulnerable, you are completely and utterly pwned as if the exploiter were sitting there with physical access to the box. Minus the physical bits.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Monday May 08 2017, @12:39AM (1 child)
I don't suppose they involve Natalie Portman and hot grits.
(Score: -1, Flamebait) by Anonymous Coward on Monday May 08 2017, @03:45AM
Natalie Portman
Why did you bring a jewess into the discussion?
I guess that could be because the jews are involved in this invasion of our privacy and the destruction of our freedom and what we build.
(Score: 2) by kaszz on Monday May 08 2017, @02:17AM (2 children)
One way to thwart AMT may be to use the network switch, to simply block TCP port 16992 and 16993. In addition only allow the Ethernet MAC of the real network card to pass the switch.
A little more hardcore version could send ping to each machine. If the machine respond correctly it will be allowed to use the rest of IP protocols, otherwise not. The point being that backdoor access and exfiltration needs a larger part of IP protocols to work before it can start.
(Score: 2) by maxwell demon on Monday May 08 2017, @09:06AM (1 child)
That only works if you only ever connect the machines to networks you control. Which might not be the case for laptops.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by kaszz on Monday May 08 2017, @09:38AM
Time for a network "condom" .. :-))
A quick solution is a Raspberry-Pi with an additional network interface. Or a home router that runs OpenWRT etc. Completely sucks. Hopefully someone will start to sue.
(Score: -1, Flamebait) by Anonymous Coward on Monday May 08 2017, @06:22AM (2 children)
Told you this years ago. You didn't believe, you pro-women's rights, anti-marry-girl-children feminist cunts.
--MikeeUSA--
(Score: 0) by Anonymous Coward on Monday May 08 2017, @09:41AM (1 child)
Me H1-B do strnnnnncmp() very good. No problem. Or just plainly got the diploma HR required but no conscientious nor brain to go with it.
I think you missed where the problem lies.
(Score: -1, Troll) by Anonymous Coward on Tuesday May 09 2017, @09:28AM
Very well. VERY __WELL__.
Stop shitting
in the Street,
Pajeet!
VPro/ME/AMT/whatever they call it next is a government mandated(or rather suggested) backdoor. Clipper chip mk 2.0.
AMD and ARM have a similar thing (Trust Zone(TM)).
Keeps the world safe for society (women) and men down (no child brides).