
The hijacking flaw that lurked in Intel chips is worse than anyone thought - podiki
https://arstechnica.com/security/2017/05/the-hijacking-flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought/
======
benchaney
I wish that this security incident would get more attention. It seems
fundamentally unfair that some projects that are essentially volunteer labor
get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets
mostly ignored.

~~~
DKnoll
If scrutiny improves the project it's ultimately a good thing.

~~~
d33
...which is exactly why Intel chips should get it too.

~~~
DKnoll
Totally, but what I'm saying is it's not unfair, it's an inherent benefit of
OSS.

------
tyingq
There's two things that don't get mentioned much with this issue.

1\. There's a second bug that allows non-root local users to provision AMT. _"
An unprivileged local attacker could provision manageability features"_[1]

2\. Access to AMT allows you to boot a recovery image, mount local drives, and
do whatever you like with the included remote KVM.[2][3]

So, even if this is turned off, there are issues to address. If it's on, they
have control of the whole machine, remotely. It's as bad as it can get.

[1] [https://security-
center.intel.com/advisory.aspx?intelid=INTE...](https://security-
center.intel.com/advisory.aspx?intelid=INTEL-SA-00075)

[2] [https://software.intel.com/en-
us/node/681803](https://software.intel.com/en-us/node/681803)

[3] [https://software.intel.com/en-
us/node/674998](https://software.intel.com/en-us/node/674998)

------
Cyph0n
There is a great comment linked at the bottom of the article that explains
what exactly caused the authentication bug (it was strncmp!). Is there somehow
a law that states that the higher the severity of a software bug, the simpler
the reason behind it?

~~~
chmaynard
From the comment:

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

~~~
benchaney
strcmp has its own issues. What they actually should have done is use a
cryptography library with properly implemented comparison, because it is
surprisingly easy to get wrong.

Also, fixed length hashes aren't strings. They shouldn't use the same
functions as strings.

Edit: Using a proper cryptography library also might have saved them from
using MD5. At the very least, most modern libraries have a warning that is is
deprecated and should not be used for new projects.

~~~
dom0
Yep, even if they had used memcmp/strncmp correctly the AMT would still be
vulnerable to a timing attack here, which is probably even easy, because it
runs on a low-power system with, I assume, not much background activity.

~~~
benchaney
In addition to timing attacks, if the attacker supplied a non null terminated
string, it could potentially cause a memory overrun. This may not be possible
depending on how the string is handled on ingress, but if it is, it would
likely have serious consequences.

~~~
qb45
The attacker supplies ""-enclosed string and the HTTP parser is supposed to
verify this.

Maybe they used some in-place HTTP parser and that's why they didn't have
zero-termination to use strcmp.

And btw, it's not clear if the code was C to begin with. I believe large chunk
of ME firmware is said to be written in Java, which kinda makes sense for a
network facing system considering how shitty _string.h_ is.

It would be interesting if somebody found that they are using some COTS
webserver, C/Java - doesn't matter, and see if there are some CVEs for it.

~~~
benchaney
I doubt using Java would really help in this case, because in order to use
Java they would have to port the entire JVM to whatever platform they are
using. Doing this without introducing any security bugs is about as difficult
as just doing everything in C to begin with. By the way, the fact that the
issue was with strncmp very strongly suggests that the issue was in C code.

~~~
dom0
Some security paper showed ARM disassembly of the issue, although I'm not sure
if that was _this specific_ issue or just another "strncmp-induced" issue.

(Btw. there are many smaller Java VMs for stuff like Java Card and JEFF)

------
ComodoHacker
So where all this authentication and web UI code resides? Is it in the BIOS?
Is there somewhere a packed JQuery or something?

~~~
tyingq
It's in the AMT code, written in C, in the management engine processor...which
is separate from the main processor. See: [https://software.intel.com/en-
us/node/631399](https://software.intel.com/en-us/node/631399)

They are using HTTP Digest Authentication, which is built into browsers. The
purpose was to keep passwords from being clear text over regular http
connections.

So, the code on the client side is in the browser. The code on the server side
is in the management processor, and it is a C implementation of HTTP Digest
Auth.

The bug is that they used strncmp, but used the length of the incoming hash
from the client as the string length to compare, versus the actual length that
the hash string is supposed to be. The exploit is to send an empty hash. That
requires a proxy, or browser plugin, since the browser creates the Digest Auth
Headers. The empty hash causes something like strncmp(expected,
received_hash_string, 0), and of course, two zero length strings are equal.

~~~
jjnoakes
> The bug is that they used strncmp, but used the length of the incoming hash
> from the client as the string length to compare, versus the actual length
> that the hash string is supposed to be.

Ignoring timing attacks, they should have used strcmp(), not strncmp().
strncmp() is for testing if one string is a prefix of another; they wanted to
test if some string equaled another.

Since this is crypto related stuff, though, they should be using a
strcmp()-like routine that works in a content-independent timing fashion.

~~~
adkafka
But using strcmp could result in buffer overflow, no?

~~~
jjnoakes
How so? We aren't talking about strcpy(), just strcmp(), and all the strings
in question should be nul-terminated (if they aren't then mem* routines should
be used and more length checks would be needed; there are also timing attacks
to worry about if we're considering all the possible issues).

But normally strncmp isn't safer than strcmp. They just do different things.

------
mjw1007
One interesting note in the article: « unauthorized accesses typically aren't
logged by the PC because AMT has direct access to the computer's network
hardware. »

That's unsurprising now I think about it, given how AMT works, but aren't the
sort of companies that would want to use AMT also the sort of companies that
have security policies that require all such things to be logged?

------
lima
I disagree with the article. If anything, it's much less severe than many
people thought.

\- It's a logic bug (authentication bypass) instead of a memory corruption. An
authentication bypass is bad, but a full compromise would have been much
worse.

\- It's a bug in the opt-in AMT management, which means that the default
config is not vulnerable.

~~~
lightedman
"An authentication bypass is bad, but a full compromise would have been much
worse."

Given the authentication bypass essentially leads to full compromise, where's
the difference, here?

~~~
qb45
The difference is, you are no longer limited to functionality normally
provided by AMT. Maybe AMT doesn't offer the ability to download arbitrary
memory locations from the running OS and applications, with remote code
execution on the ME you could do that. You could modify code running on the
CPU on-the-fly and make it read files from disk to memory for downloading too
- again, I don't think AMT can read disks, especially when the OS is running
and using them concurrently.

~~~
tyingq
You can boot a recovery image though, and edit files on the installed OS that
way.

~~~
qb45
It just isn't quite as stealthy if you have to power up the box when it's
supposed to be off.

I mean, not everybody runs Windows 10 and is used to his machine having a free
will of its own ;)

------
geofft
At what point does it become reasonable to conclude that strncmp, and every
other string API that treats the pointer to the string and its length as
separable variables, are too dangerous to be used in security-sensitive
software? I feel like I've seen another vulnerability _this week_ from someone
sending the wrong length to a standard C string function.

If you want to fix this, there's no strict need to move away from C (not that
I'd particularly encourage you to stay, but if you have some reason to prefer
C, you can solve this in C). There are a number of C libraries that give you a
struct string {char *ptr; int len;} of some sort, from bstring to GLib. And
there's always C++, too.

What need does the Intel AMT firmware have for compatibility with POSIX string
APIs? It's not running a POSIX OS, is it?

~~~
code_sloth
Could you elaborate on why "treating the pointer to a string and the string
length as separate vars" is dangerous to someone who hasn't done a lot of C?

~~~
pabl0rg
If you access a memory location beyond the end of the string, you can get all
sorts of unexpected behavior. The string's length is something you'll pretty
much always need to take into account.

~~~
DaiPlusPlus
Many libraries and systems (e.g. Win32) just go with null-terminated strings
and their functions don't accept a length argument at all - so I wonder if
some people never store the length simply because they don't believe they'll
ever need it.

------
lisper
It just keeps getting better: Intel's diagnostic tool is published with an MD5
checksum.

~~~
megadollar
That's fine. I will literally give you $10,000 if¹ you can give me a MD5
preimage attack. Take your attack vector to be that particular md5sum that you
are making fun of.

MD5 is not broken for the usage that you think it's broken for. Please don't
snipe on things like this again. People like you who say things like "md5 is
always bad" or "you should bcrypt, duh" are literally cargo culting the idea
of computer security.

In addition to the fundamental technical deficiency you've demonstrated,
people who opine on security threads while not quite understanding anything
about computer security allow charlatans to sell "computer security". Every
single comment like this lends credence to literal scam artists.

¹note, this is actually a prize for a weaker claim than an preimage attack;
all I want is a second preimage (!)

~~~
benchaney
The reason that people move away from a hash function when it looses collision
resistance is that collision resistance serves as a measure of the security
margin for preimage resistance. Cryptographic primitives are intended to be
rotated out of use about 10-15 years before they become actually broken for
their intended purpose. Unless you are willing to extend you bounty to the
year 2030 it is means nothing.

In addition, you are completely wrong about the harm caused by simplifying the
rules of thumb for security. There is not good reason to ever use MD5 for this
purpose, and saying "MD5 is ok in some cases" has the potentially to do far
more harm than "never use MD5".

> note, this is actually a prize for a weaker claim than an preimage attack;
> all I want is a second preimage (!)

Don't act like you are doing GP a favor, second preimage is the attack that
would cause a vulnerability in this usage of MD5.

You are the one who is"opin[ing] on security threads while not quite
understanding anything", so I think before the next time you condescendingly
correct someone you should make sure you have a basic understanding of what
you are talking about.

~~~
megadollar
You're clearly somebody who wants to rely on "rules of thumb" for security.
I'm arguing against the entire concept of rules of thumb and you've since
argued against a strawman. Did I ever say "MD5 is ok in some cases"?

Aside: a preimage attack implies a second preimage attack.

~~~
benchaney
>You're clearly somebody who wants to rely on "rules of thumb" for security.
I'm arguing against the entire concept of rules of thumb

Not all devs are security experts, or can even afford to focus on security. To
deny the value of rules of thumb is to deny that they need to consider
security.

> Did I ever say "MD5 is ok in some cases"?

Oh, really? Were you not arguing that MD5 is ok if you only need preimage
resistance?

> MD5 is not broken for the usage that you think it's broken for. Please don't
> snipe on things like this again. People like you who say things like "md5 is
> always bad" or "you should bcrypt, duh" are literally cargo culting the idea
> of computer security.

Hmm. Seems like you were...

------
dataminded
This is a dream come true for AMD.

~~~
Neliquat
AMD has a similar system, likely with simular issues. Their smaller footprint
means they just take longer for people to notice than an Intel snafu.
Hopefully this will give them a preemptive heads up to harden theirs before an
exploit is discovered.

~~~
rocqua
AMD made some noise (way before this vulnerability became known) about open-
sourcing the code of their ME-equivalent and allowing people to flash their
own code.

That seems a lot better than Intel's stance on the ME.

~~~
Unklejoe
Unless something new happened that I'm unaware of, it was more like "the
people of Reddit made some noise in an AMA, and AMD basically said "we'll look
in to it"".

------
ForFreedom
Should be more like a backdoor that NSA/CIA can walk in rather than hijacking
flaw or "OH! I didnt know there was a flaw!"

Surely a new one must have been created since NSA tools are out on the net

------
Myrmornis
Is the amount of attention this is getting commensurate with how
interesting/surprising/consequential a security flaw it is?

~~~
DKnoll
I don't think it's just that the flaw exists, which alone is pretty bad, but
how widely deployed it is in large enterprise, coupled with Intel ignoring it
after being given years of notice and also the unease about AMT in the OSS
community since it's deployment. To be honest, I doubt 9/10 people who care
about this are going to stop using Intel, but it's still a comedy of errors
and I think everyone loves a spectacle.

~~~
lima
> Intel ignoring it after being given years of notice

Sure about that? From what I can tell, it's a recently discovered
vulnerability that was promptly fixed.

~~~
DKnoll
According to SemiAccurate (terrible name for a source) they reported it to
Intel some time ago.

~~~
lima
As far as I know, Embedi and not SemiAccurate found and reported the issue.

[https://www.embedi.com/files/white-papers/Silent-Bob-is-
Sile...](https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf)

> An authentication bypass vulnerability, which will be later known as
> CVE-2017-5689, was originally discovered in __mid-February of 2017 __while
> doing side-research on the internals of Intel ME firmware. The first objects
> of interest were network services and protocols.

------
CodeWriter23
Interesting how this article steadfastly refers to the subsystem as AMT and
never mentions Management Engine/ME. A deliberate ploy to redirect people away
from discovering all the ME-disabling research and tech? Perhaps. This is what
happens when "journalists" post copypasta from publicists.

~~~
ars
I quote: "When AMT is enabled, all network packets are redirected to the Intel
Management Engine"

~~~
jgaa
As far as I know, it's only doing this for the primary (on-chip) network
interface. /Never/ use the primary NIC if you have a Intel CPU.

