Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rediscovering the Intel AMT Vulnerability

tenable.com

Post reply on HN
Print view View original

1–10 of 94 posts

Re: Rediscovering the Intel AMT Vulnerability

#3

Post by fhood »

DuskStar wrote: post #2

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

To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.

Re: Rediscovering the Intel AMT Vulnerability

#4

Post by MichaelGG »

So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box?

Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?

Re: Rediscovering the Intel AMT Vulnerability

#5

Post by FrozenVoid »

DuskStar wrote: post #2

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

see https://threatpost.com/researcher-baseless-assumptions-exist...

Re: Rediscovering the Intel AMT Vulnerability

#6

Post by qb45 »

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 satisfy pedants below ;)

Re: Rediscovering the Intel AMT Vulnerability

#7

Post by bobsam »

MichaelGG wrote: post #4

So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box? Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?

Many enterprise users are affected by this.

Re: Rediscovering the Intel AMT Vulnerability

#8

Post by MichaelGG »

bobsam wrote: post #7
MichaelGG wrote: post #4

So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box? Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?

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.

Re: Rediscovering the Intel AMT Vulnerability

#9

Post by Karunamon »

fhood wrote: post #3
DuskStar wrote: post #2

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

To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.

That's more of an argument about inauditable, non-disableable, hostile (the CPU shuts itself off if you blank out the appropriate data structures) code running below ring 0
Post reply on HN