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

81–90 of 94 posts

Re: Rediscovering the Intel AMT Vulnerability

#81

Post by paulmd »

lucb1e wrote: post #47
qb45 wrote: 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…

> [...] how to create equivalent bug in Java, the obvious string.equals() method [...] Java Card, the Java version made for smart cards, does not have strings, and thus no String.equals(). Thought I remembered this from a CCC conference about EMV chips or SIM cards (don't remember which) a few years ago. Googling seems to confirm it: https://community.oracle.com/thread/1751610?db=5

From what I remember in one of the deep teardowns it's possibly Java ME (which I think is one step above Java Card in terms of features). The file format is JEFF.

Re: Rediscovering the Intel AMT Vulnerability

#82

Post by paulmd »

jfoutz wrote: post #64
justinclift wrote: post #63

Earlier quoted context omitted.

> If they're embedding an entire oracle JVM then it's probably pretty safe. This sounds a bit strange to me. Oracle releases a lot of updates for the JRE. eg Java 8 is up to number 131 at the time of writing this, though they're probably (hopefully!) not all security updates: • http://www.oracle.com/technetwork/java/javase/downloads/inde... • http://www.oracle.com/technetwork/java/javase/8u-relnotes-22... With that i…

Oracle JVM is a huge and complicated beast, it's a ridiculous thing to embed in a chip. On the other hand, it's thoroughly tested, and security vulnerabilities are (generally?) fixed in a timely fashion. A home made, completely un audit able, built in JVM (that apparently can't be updated based on your comments) seems crazy dangerous. Just saying "it's probably ok, because it's java" as the op alluded to is a very da…

To put this another way, JVM as a conceptual processor is pretty solid and I doubt there are many massive errors in the design. Your homebrew JVM implementation certainly may contain errors, and the software built on any JVM almost certainly does.

Re: Rediscovering the Intel AMT Vulnerability

#83

Post by semi-extrinsic »

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?

I also understand AMT is only found on vPro branded CPUs, which most consumers don't buy.

You can search here to get a list; e.g. select {vPro: yes, Embedded graphics: yes} to see "normal" CPUs that are affected.

http://ark.intel.com/Search/Advanced

Re: Rediscovering the Intel AMT Vulnerability

#84

Post by qb45 »

throw2016 wrote: post #74
qb45 wrote: post #52

Earlier quoted context omitted.

Unfortunately, a "management engine" with some degree of control over the CPU is necessary for, well, management. As in remote management, which is something that big corps with thousands of machines want, and the more control it gives the better. The code itself is as secret as the code of any proprietary Windows-based remote administration tool they could supply as a poor man's substitute if the ME didn't exist. It…

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel pr…

> If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium.

AMT is positioned as enterprise exclusive with a price premium, that's how Intel's pricing usually works. The underlying hardware (the ME) is not, because it's used for other things too. On old chipsets you can clear the ME firmware and the computer will miss some weird features but otherwise work, on newer chipsets it won't work at all. That's why every chip has the ME even if many chips don't have the AMT.

> The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence.

AMD: not coincidence, competition.

ARM: See the sibling post.

Re: Rediscovering the Intel AMT Vulnerability

#85

Post by qb45 »

duskwuff wrote: post #80
throw2016 wrote: post #74

Earlier quoted context omitted.

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel pr…

> The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. Don't believe the FSF's FUD. TrustZone is really not comparable at all to Intel's Management Engine or AMD's Secure Processor: * TrustZone is an operating mode of the CPU, not a separate processor. Fundamentally, it's not all that different from supervisor mode; it's just more privileged. (If you really w…

> Don't believe the FSF's FUD

Don't believe anti-FSF FUD. If you think they have an issue with TrustZone itself, as opposed to devices using it without owner's control, I'd love to see the links.

Re: Rediscovering the Intel AMT Vulnerability

#86

Post by mirimir »

mdip wrote: post #76
kbenson wrote: post #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…

Wow. Just Wow. After reading about this over several days I would have never guessed it was such a gaping hole. This reminds me of a software bug I encountered in the 90s with a version of the Renegade BBS software (a Telegard hack). In one minor revision, you could login to any account by just not bothering to enter a password. Though the "sysop" (admin) account often had a custom name, for convenience, you could lo…

So what might the coding error have been? I mean, it seems like null password matches any password. Parsing null can be hard, but seriously?

Re: Rediscovering the Intel AMT Vulnerability

#87

Post by mirimir »

jerf wrote: post #78
kbenson wrote: post #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…

Well... I agree with you in principle, but in practice I find developers often to forget that code fails the way it is supposed to fail, when it is supposed to fail. In the authentication case, everyone remembers to check that when you're supposed to be logged in, you can access what you should be able to access. But it's really common to not think to test that when you're not logged in you shouldn't be able to acces…

I hope that's more unlikely than you say.

Re: Rediscovering the Intel AMT Vulnerability

#88

Post by kingosticks »

qb45 wrote: post #84
throw2016 wrote: post #74

Earlier quoted context omitted.

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel pr…

> If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. AMT is positioned as enterprise exclusive with a price premium, that's how Intel's pricing usually works. The underlying hardware (the ME) is not, because it's used for other things too. On old chipsets you can clear the ME firmware and the computer will miss…

> AMD: not coincidence, competition

For the sake of argument more than anything, were AMD even remotely competitive with Intel in the enterprise sector at the time they introduced their version of this technology? Sure, they might need it one day (which may be soon) and it'd be nice to have it out there and supported, but I'm not totally convinced by this argument.

Re: Rediscovering the Intel AMT Vulnerability

#90

Post by snvzz »

duskwuff wrote: post #80
throw2016 wrote: post #74

Earlier quoted context omitted.

This is a bit of a fig leaf. If it was just for enterprise users there would be no reason to impose it on everyone. It would be positioned as an enterprise exclusive with a price premium. The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. All the signs point to bad actors but for some the bar of evidence is either another Snowden level sacrifice or Intel pr…

> The fact that both AMD and ARM integrated similar technologies at around the same time is too much coincidence. Don't believe the FSF's FUD. TrustZone is really not comparable at all to Intel's Management Engine or AMD's Secure Processor: * TrustZone is an operating mode of the CPU, not a separate processor. Fundamentally, it's not all that different from supervisor mode; it's just more privileged. (If you really w…

>If you really wanted, you could probably write an OS that ran parts of the kernel in TrustZone.

https://genode.org/documentation/articles/trustzone

Post reply on HN