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