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