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.
Rediscovering the Intel AMT Vulnerability
11–20 of 94 posts
Re: Rediscovering the Intel AMT Vulnerability
#12Intel 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.
Well, even if you completely trust Intel to never be nefarious, never act against your best interest, never do anything shady whatsoever with that power, you can't trust them to keep that power only for their own use. This vulnerability is proof of that.
So you don't have to claim that Intel could have bad faith. You can claim, with proof, that Intel has less than perfect success at security, and that less than perfect security is reason enough why this "secret computer inside" is a horrible idea.
Re: Rediscovering the Intel AMT Vulnerability
#13Earlier quoted context omitted.
Many enterprise users are affected by this.
Sure but they'd be affected regardless, due to enabling a remote management system. All I'm asking is if there's any real damage because this is built in by Intel. If Intel didn't ship this, then OEMs would, just like e.g. Dell DRAC, right? And that'd have the same attack surface.
But, IIUC, this has more power once exploited.
Re: Rediscovering the Intel AMT Vulnerability
#14TL;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…
No. That was another vulnerability used as an example.
In this case, if you don't send some hash, it will authenticate you, allowing you to authenticate with user `admin` and no password.
Re: Rediscovering the Intel AMT Vulnerability
#15TL;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…
No. That was another vulnerability used as an example. In this case, if you don't send some hash, it will authenticate you, allowing you to authenticate with user `admin` and no password.
The article discusses an actual partial prefix match.
> we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded!
> Next, we reduced the response hash to one hex digit and authentication still worked.
This doesn't imply that "no password" - an empty password would still result in a non-empty HTTP Authorization Digest response hash, which would not allow you to login. An empty/truncated digest response hash is not the same thing as an empty/truncated password.
Re: Rediscovering the Intel AMT Vulnerability
#16Re: Rediscovering the Intel AMT Vulnerability
#17[deleted]
Re: Rediscovering the Intel AMT Vulnerability
#18[withdrawn]
Re: Rediscovering the Intel AMT Vulnerability
#19[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.
Re: Rediscovering the Intel AMT Vulnerability
#20So the AMT vuln was related to a lack of security on their web service? Somehow this does not increase my confidence in the rest of their code - if they didn't get this right, what else is wrong?
The Intel note mentioned a local vulnerability that allowed local non root users to provision AMT as well. That sounds like at least one more, different, issue.