News for hackers. Stuff that matters.
Re:Disabling the Intel Management Engine by platinumrad on Tuesday October 10, 2017 @05:54PM (#15445648)
The IME, like Computrace which is similarly awful[1], is intended to be used for enterprise management. It's nice for someone in IT to be able to remotely wipe a company laptop that was left in an airport, but there's absolutely no reason why consumer devices should be burdened with these backdoors.

AMD has something called the PSP which essentially serves the same purposes of the IME which is also undocumented and cannot be disabled.

[1] https://securelist.com/absolute-computrace-revisited/58278/

Re:Disabling the Intel Management Engine by JumpCrisscross on Tuesday October 10, 2017 @06:25PM (#15445834)
> there's absolutely no reason why consumer devices should be burdened with these backdoors

Intel's advantage is built and defended on economies of scale. Making a hundred million of one thing [1] is more profitable than making 50 million of two things. Particularly if enterprises' demand for IME is stronger than consumers' demand for non-IME chips (assuming no strong externalities, e.g. NSA corruption).

I think the Intel Management Engine is crap. But there's a comprehensible reason it's there.

[1] https://www.ft.com/content/beff6e56-53ed-11e4-80db-00144feab...

Re:Disabling the Intel Management Engine by platinumrad on Tuesday October 10, 2017 @06:47PM (#15445945)
Intel doesn't have to ship IME-less chips. All it has to do is provide a way for users[1] to disable features that compromise their security but Intel doesn't, for whatever reason.

[1] I'm aware that a "High Assurance Program" bit exists that disables most functions of the IME but you can't expect the average consumer (or even the majority of technically-inclined consumers) to own an SPI flash programmer and to be willing and able to use one on their motherboard. Furthermore, researchers believe that setting this bit would cause any computer with the Verified Boot fuses set (i.e. pretty much any recent laptop) to fail to boot[2].

[2] https://github.com/corna/me_cleaner/issues/53#issuecomment-3...

Re:Disabling the Intel Management Engine by lukewink on Tuesday October 10, 2017 @06:51PM (#15445966)
Economies of scale doesn't explain why there isn't an option to disable the IME.
Re:Disabling the Intel Management Engine by acdha on Tuesday October 10, 2017 @09:23PM (#15446635)
> there's absolutely no reason why consumer devices should be burdened with these backdoors.

Beyond the obvious economy of scale argument, why don’t consumers want that? I thought things like Apple’s remote lock/wipe feature were selling points for anyonel concerned with theft.

(As an aside, it doesn’t feel accurate to term this a backdoor without evidence that it’s being used without the owner’s consent)

Re:Disabling the Intel Management Engine by snarfy on Wednesday October 11, 2017 @07:04AM (#15448752)
The article mentions they've already found a remotely exploitable security hole. Backdoor or not, nobody wants that.

We would all be fine with IME if we had access to it, could define the keys, and enable/disable features of it. Locking users out of their own hardware is not acceptable. I'm the only one that should be able to remote lock/wipe my phone. It should not be possible for Apple. They shouldn't have the keys. It's my phone. Even if I did trust Apple, I don't trust the government.

Re:Disabling the Intel Management Engine by acdha on Wednesday October 11, 2017 @10:51AM (#15450226)
Look, I’d also like this to be open and documented but hyperbole isn’t helping that. If it’s undocumented, say that rather than pretending anyone is locked out of their own hardware — nobody has lost the use of their device due to IME. Similarly, calling it a backdoor and implying that the NSA is behind it without any proof is only going to reflect badly on the person making those claims.

The other thing to remember for effective advocacy is thinking about what normal people experience. If you say Apple shouldn’t have the keys, you’re also saying the average person has to be good at key management; most people are happy to outsource that. Conflating the issues of mass surveillance with control over your own hardware is great if your goal is confusion but I don’t see it producing results.

Re:Disabling the Intel Management Engine by zAy0LfpBZLC8mAC on Tuesday October 10, 2017 @10:46PM (#15446952)
Whether it is actually being used is irrelevant. Security is about confidence that unauthorized access is impossible, not about whether unauthorized is happening right now. An unlocked door is not secure against unauthorized entry merely because noone has opened it yet, what makes it insecure is the fact that anyone who wants to can walk through it whenever they want.

It is not even relevant whether the door was left unlocked intentionally. An unlocked door is a security problem, whether it was put in place intentionally or due to negligence.

Re:Disabling the Intel Management Engine by acdha on Tuesday October 10, 2017 @11:20PM (#15447054)
That’s not what we’re talking about, though, is it? Unless the claim is that vendors are shipping IME enabled with secret credentials it’s not a backdoor.
Re:Disabling the Intel Management Engine by zAy0LfpBZLC8mAC on Wednesday October 11, 2017 @12:38AM (#15447325)
A backdoor does not necessarily have to be in the form of a door, a wall made from cardboard will do just fine as a backdoor.

Putting a complex piece of software that you cannot disable, that is potentially reachable from the network, and that won't be updated into every machine is the software-equivalent of building a safe with a cardboard wall: Even if it's not intended as a backdoor, it still has to be treated as a de-facto backdoor for security planning purposes, and whoever uses cardboard to construct a safe wall is to blame.

Also, you do not judge security based on what has already happened nor on what you can prove to be insecure. The default assumption is that things are insecure, unless you can demonstrate that there are good reasons to believe that it's not--just as everywhere else in reliability engineering. A bridge is not assumed to be safe to use until it collapses or is demonstrated to be unsafe--a bridge is assumed to be unsafe to use until it is demonstrated that to the best of our current understanding of how to build reliable bridges, there is no reason to expect failure. A bridge where the builder makes a secret out of how the bridge was built is never considered safe.

Re:Disabling the Intel Management Engine by comatose on Wednesday October 11, 2017 @01:05AM (#15447427)
Imagine your pc vendor shipped windows with remote desktop enabled, you can't disable it, and you can't see if there are any local accounts in the group, and also they could be administrators, and also it was far worse than even that, because the computer doesn't have to be on or connected to a lan. imagine if dell shipped with logmein and wol but it was permanent. how are these not security vulnerabilities?
Re:Disabling the Intel Management Engine by platinumrad on Tuesday October 10, 2017 @10:54PM (#15446980)
They're backdoors because they allow for remote access[1] and we (as in the users who ostensibly "own" our own devices) can't turn them off without going through great difficulty.

Please read the piece linked above on Computrace. I am not very familiar with the inner workings of Find My Mac and other AppleID-associated features but I'm going to go out on a limb and say that those features 1. don't involve injecting code into system processes in the exact same manner as a BIOS-level rootkit and 2. aren't preactivated without the owner's knowledge or consent so the attack surface they create is likely much smaller than that of something like Computrace.

Also, if you like, please elaborate on why the economy of scale argument is "obvious".

[1] https://arstechnica.com/information-technology/2017/05/intel...

Edit: Management coprocessors are also rightly called backdoors because they operate below ring 0 meaning that if we cannot trust them (and we can't because they are largely black boxes to us) then we cannot trust our systems as a whole.