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