4 ms·

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

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/ https://securelist.com/absolute-computrace-revisited/58278/

JumpCrisscross 9y ago
> 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-00144feab7de https://www.ft.com/content/beff6e56-53ed-11e4-80db-00144feab...
- platinumrad 9y ago
  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-325589606 https://github.com/corna/me_cleaner/issues/53#issuecomment-3...
- lukewink 9y ago
  Economies of scale doesn't explain why there isn't an option to disable the IME.
acdha 9y ago
> 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)
- zAy0LfpBZLC8mAC 9y ago
  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.
  - acdha 9y ago
    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.
    - zAy0LfpBZLC8mAC 9y ago
      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.

JumpCrisscross 9y ago

> 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-00144feab7de https://www.ft.com/content/beff6e56-53ed-11e4-80db-00144feab...

platinumrad 9y ago
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-325589606 https://github.com/corna/me_cleaner/issues/53#issuecomment-3...
lukewink 9y ago
Economies of scale doesn't explain why there isn't an option to disable the IME.

acdha 9y ago

> 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)

zAy0LfpBZLC8mAC 9y ago
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.
- acdha 9y ago
  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.
  - zAy0LfpBZLC8mAC 9y ago
    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.