Live data from Hacker News

Rediscovering the Intel AMT Vulnerability

tenable.com

21–30 of 94 posts

Re: Rediscovering the Intel AMT Vulnerability

#21

[withdrawn]

I'm not sure what you're trying to say -- we can't discuss IME being a second computing system inside of your computer controlled by someome else? Because I seem to have just done that. We can even talk about why the existence of that system is problematic, since it gives someone else control over "your" computer.

[withdrawn]

Re: Rediscovering the Intel AMT Vulnerability

#23
Next, we 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.

What. the. fuck.

This is not the kind of bug you should ship in anything if you have the barest bit of testing in place, much less a large company like Intel, in an enterprise feature which has a lot of security ramifications, and which has apparently existed for a long time (years?).

Edit: Also, this is really good evidence for short and hard disclosure deadlines. What's the chance something as simple as this wasn't known by someone else? All they had to do was decide to look and they found something within minutes. It's not like this is obscure or doesn't get your much, it's about as juicy as they come.

Re: Rediscovering the Intel AMT Vulnerability

#24
post #10

Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching. That's the problem you should discuss, not this particular exploit.

Having a "management engine" with direct access to the network and to memory is questionable in itself. Its code being secret indicates there's probably something bad going in. If it only does what Intel says it does, it doesn't need to be secret.

Re: Rediscovering the Intel AMT Vulnerability

#25
If AMT provides remote management of devices that are turned off, what program provides authentication of remote management requests when the OS is powered off? Has that interface been audited for authentication vulnerabilities?

If there is an OS-independent, network-accessible AMT management service, when would an admin need to switch from that service to the Windows-hosted web interface? Why can't all AMT operations be performed without an OS?

Re: Rediscovering the Intel AMT Vulnerability

#26
post #11
post #10

Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching. That's the problem you should discuss, not this particular exploit.

So has AMD.

Have you seen their reddit AMA regarding this?

Re: Rediscovering the Intel AMT Vulnerability

#27
The article says that a Local Management Service (LMS) must be installed for the bug to be demonstrated[0], and describes a Windows package that provides that. Is there a Linux equivalent?

[0] I say "demonstrated" instead of "exploited", since I don't understand the details sufficiently to rule out exploitation in the absence of LMS.

Re: Rediscovering the Intel AMT Vulnerability

#28
post #24
post #10

Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching. That's the problem you should discuss, not this particular exploit.

Having a "management engine" with direct access to the network and to memory is questionable in itself. Its code being secret indicates there's probably something bad going in. If it only does what Intel says it does, it doesn't need to be secret.

IPMI falls into similar waters, and also has known design flaws around authentication. :(

Re: Rediscovering the Intel AMT Vulnerability

#29
post #6

TL;DR: memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len) Hey, at least they didn't read past the submitted buffer. edit: Note that this is only pseudocode and rumor has it that ME firmware is actually written mostly in Java. It's not immediately clear to me how to create equivalent bug in Java, the obvious string.equals() method doesn't ignore length mismatch. edit2: s/passwd/passwd_hash to satis…

Quite a bit of Java memory safety comes from the JVM. Array bounds checking, for example. If they're embedding an entire oracle JVM then it's probably pretty safe. On the other hand, if they're compiling down to a home made vm with a home made compiler, well. who knows? Dalvik did that and it had some problems.

It seems really hard to test from the point of an outside observer. I'd strongly suspect it's hard to test internally as well, which would indicate there are a bunch of bugs lurking in there.

Re: Rediscovering the Intel AMT Vulnerability

#30
post #26
post #11

Earlier quoted context omitted.

So has AMD.

Have you seen their reddit AMA regarding this?

Not the person you were replying to but I would really want to read this, do you have a link?

edit

I think i may have found it, is it this https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...

Post reply on HN