3 ms·

You're applying several inadequate metaphors. To do the same thing, it's kind of like saying my tool box full of tools is similar to a screwdriver. No, wait, it

You're applying several inadequate metaphors. To do the same thing, it's kind of like saying my tool box full of tools is similar to a screwdriver. No, wait, it's more literally like a box to carry tools in. ;) It's hard to argue with metaphors, because they start out being inexact and go downhill from there. (oh, another one!) But I'll try anyway :) It's really nothing like group policy's or configuration profiles, except it could be used to deliver similar functionality for your machine from either the manufacturer, or from your company, or from anyone else along the way who implemented their own backdoor into your hardware during shipping[1] or maybe just inserted their own microcode into the CPU, because it literally is an all-powerful hardware backdoor that lives below your OS. It can even be upgraded remotely in many cases. Backdoors can be used for good or for evil, of course, but that's what it is. (and it actually has nothing to do with hypervisors, unless you take the metaphor that any operating system you install is really running under the control and whim of the Intel Management Engine.) Again, the metaphor of a remote management console is again over-simplifying, but, sure, it can do that, too. When you're reading this[2], remember that you don't control those keys and you can't remove that software. You can't 'just turn it off': 1. http://gizmodo.com/the-nsa-actually-intercepted-packages-to-put-backdoors-1491169592 http://gizmodo.com/the-nsa-actually-intercepted-packages-to-... 2. http://libreboot.org/faq/#intelme http://libreboot.org/faq/#intelme

derefr 11y ago
> and it actually has nothing to do with hypervisors, unless you take the metaphor that any operating system you install is really running under the control and whim of the Intel Management Engine What I meant was that, the same way the userland runs at the control and whim of the kernel, and the kernel at the control and whim of the hypervisor, the hypervisor itself will run at the control and whim of IME. Because IME sits at ring -2 (yes, that's a thing now), the hypervisor at ring -1, the kernel at ring 0, and userland at ring 3. So it's actually more than "hypervisor-level access", but a hypervisor is almost as capable, so it's a decent comparison. > ...except it could be used to deliver similar functionality... That's what I was trying to communicate, yes. The purpose (not the functionality) of IME is to enable enterprise management. Like Group Policy or Configuration Profiles, like server backplane management, like running your app as a VM on a hypervisor, like a lot of things. The point is that these technologies exist to enable companies to control and manage their hardware assets. None of them are built in such a way that they can reach out and bite you if they haven't been set up and configured by the computer's owner, any more than someone could interface with your computer's serial console without attaching a serial cable to it. A lot of devices come with privileged backdoors, for a variety of reasons. For example, a lot of CPUs have a JTAG debugger chip embedded, exposed via GPIOs. But since such backdoors require hardware access to enable, they're not all that scary. Of course your device isn't secure if someone gains physical access to it. While they were in there, they might have also installed a Bluetooth-transmitting in-line keylogger chip or something. Now, what might be scary about IME is that it's enabled by default. But a lot of things are also insecure by default until hardening is applied, and have to be secured in a clean-room environment: Windows, for example. If you care, you do this. But I don't see its existence in particular as troubling, insofar as it doesn't represent any greater loss of control than was already true. Intel chips (and I'm pretty sure those of most other CISC manufacturers) have been running microcode updated via encrypted blobs for decades; this microcode can have any number of backdoors embedded in it. You don't need a fancy special-purpose coprocessor to do this stuff; the main processor is perfectly capable of doing Intel's bidding instead of yours without any help. The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals. Note also that most firmware chips can be re-flashed to do bad things; CPUs are not alone in presenting this "bugged out-of-the-box" attack-vector. ...but then, to go one step further: if you don't trust Intel's chips because of their firmware, why does it matter whether it's firmware or not? Backdoors can be embedded in the traces of the CPU itself. Having updatable microcode doesn't change this; the existence of the IME doesn't change this. Do you think the NSA can't requisition a one-off custom variant printing of a CPU, and get that stuck the board of a Person of Interest's laptop, or phone, or TV, instead? This is why I was concentrating on the Intel AMT (remote Internet access) feature of the IME: it's the only part that materially changes things from how-the-world-was before its existence. If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port. Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do.
- jamiesonbecker 11y ago
  Awesome, I like your response. I definitely agree that there are many ways to take this. But, some of the risk factors that you are comparing aren't really on the same level. To go back to a bad metaphor again :), what if I stuck a camera with encrypted feeds in your house that you couldn't remove, but I told you that they weren't attached to anything? and that you could just push this button to turn them off? See, the light goes off. That means it's off. Why are you so distrusting? What if they were in every room? over your bed? As you move downward into more primitive levels of the system, or outward to edge parts of the system (ie a usb attachment), it becomes harder to see what's going on. For example: let's say that you p0wned the firmware on a non-boot SATA drive. You could see all the bits flying across, but you can't do much about them except tamper with them; they might be encrypted, or you maybe can't get access to the network in order to ship them off elsewhere. There's probably ways around each of those, but it's hard. But what if I took a Raspberry Pi and stuck it on the system bus? that's a different story :) When you have a multi-megabyte secondary server and processor that's hooked directly into your system bus, watching everything that comes across and able to subtly react, tamper, watch just for keys, or ship data off elsewhere, then (as you point out) the attack vectors multiply compared to a exploiting a device's firmware. And, you can't ever get rid of them. EVER. No amount of flashing will fix it, because you can't flash it anyway. (That's why I posted the libreboot IntelME link). What if just the hardware RNG (rdrand) watched for a particular sequence of bits to come into some registers, and then started spitting out a predictable sequence for random numbers? What if this wasn't even a crazy conspiracy theory? (It's not, as we know now, although we don't know the exact mechanism that hardware RNG's are owned by). :( > The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals. Yes, agreed - that's a radically different level of surface area. Any firmware can be reflashed, but this isn't just any firmware; this is firmware that connects everything together. This is literally the heart of the system. And it's completely locked off from our even viewing it, let alone choosing not to using it. > If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port Agreed, but you originally said you can disable IME, and that's all I was really taking issue with :) Disabling AMT still leaves IME: what is it doing? You don't know, and we'll never tell you ;) > Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do. Agreed. :( Thank you for the interesting discussion! It'd be fun to relax and argue about it sometime in person. :)

derefr 11y ago

> and it actually has nothing to do with hypervisors, unless you take the metaphor that any operating system you install is really running under the control and whim of the Intel Management Engine What I meant was that, the same way the userland runs at the control and whim of the kernel, and the kernel at the control and whim of the hypervisor, the hypervisor itself will run at the control and whim of IME. Because IME sits at ring -2 (yes, that's a thing now), the hypervisor at ring -1, the kernel at ring 0, and userland at ring 3. So it's actually more than "hypervisor-level access", but a hypervisor is almost as capable, so it's a decent comparison. > ...except it could be used to deliver similar functionality... That's what I was trying to communicate, yes. The purpose (not the functionality) of IME is to enable enterprise management. Like Group Policy or Configuration Profiles, like server backplane management, like running your app as a VM on a hypervisor, like a lot of things. The point is that these technologies exist to enable companies to control and manage their hardware assets. None of them are built in such a way that they can reach out and bite you if they haven't been set up and configured by the computer's owner, any more than someone could interface with your computer's serial console without attaching a serial cable to it. A lot of devices come with privileged backdoors, for a variety of reasons. For example, a lot of CPUs have a JTAG debugger chip embedded, exposed via GPIOs. But since such backdoors require hardware access to enable, they're not all that scary. Of course your device isn't secure if someone gains physical access to it. While they were in there, they might have also installed a Bluetooth-transmitting in-line keylogger chip or something. Now, what might be scary about IME is that it's enabled by default. But a lot of things are also insecure by default until hardening is applied, and have to be secured in a clean-room environment: Windows, for example. If you care, you do this. But I don't see its existence in particular as troubling, insofar as it doesn't represent any greater loss of control than was already true. Intel chips (and I'm pretty sure those of most other CISC manufacturers) have been running microcode updated via encrypted blobs for decades; this microcode can have any number of backdoors embedded in it. You don't need a fancy special-purpose coprocessor to do this stuff; the main processor is perfectly capable of doing Intel's bidding instead of yours without any help. The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals. Note also that most firmware chips can be re-flashed to do bad things; CPUs are not alone in presenting this "bugged out-of-the-box" attack-vector. ...but then, to go one step further: if you don't trust Intel's chips because of their firmware, why does it matter whether it's firmware or not? Backdoors can be embedded in the traces of the CPU itself. Having updatable microcode doesn't change this; the existence of the IME doesn't change this. Do you think the NSA can't requisition a one-off custom variant printing of a CPU, and get that stuck the board of a Person of Interest's laptop, or phone, or TV, instead? This is why I was concentrating on the Intel AMT (remote Internet access) feature of the IME: it's the only part that materially changes things from how-the-world-was before its existence. If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port. Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do.

jamiesonbecker 11y ago
Awesome, I like your response. I definitely agree that there are many ways to take this. But, some of the risk factors that you are comparing aren't really on the same level. To go back to a bad metaphor again :), what if I stuck a camera with encrypted feeds in your house that you couldn't remove, but I told you that they weren't attached to anything? and that you could just push this button to turn them off? See, the light goes off. That means it's off. Why are you so distrusting? What if they were in every room? over your bed? As you move downward into more primitive levels of the system, or outward to edge parts of the system (ie a usb attachment), it becomes harder to see what's going on. For example: let's say that you p0wned the firmware on a non-boot SATA drive. You could see all the bits flying across, but you can't do much about them except tamper with them; they might be encrypted, or you maybe can't get access to the network in order to ship them off elsewhere. There's probably ways around each of those, but it's hard. But what if I took a Raspberry Pi and stuck it on the system bus? that's a different story :) When you have a multi-megabyte secondary server and processor that's hooked directly into your system bus, watching everything that comes across and able to subtly react, tamper, watch just for keys, or ship data off elsewhere, then (as you point out) the attack vectors multiply compared to a exploiting a device's firmware. And, you can't ever get rid of them. EVER. No amount of flashing will fix it, because you can't flash it anyway. (That's why I posted the libreboot IntelME link). What if just the hardware RNG (rdrand) watched for a particular sequence of bits to come into some registers, and then started spitting out a predictable sequence for random numbers? What if this wasn't even a crazy conspiracy theory? (It's not, as we know now, although we don't know the exact mechanism that hardware RNG's are owned by). :( > The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals. Yes, agreed - that's a radically different level of surface area. Any firmware can be reflashed, but this isn't just any firmware; this is firmware that connects everything together. This is literally the heart of the system. And it's completely locked off from our even viewing it, let alone choosing not to using it. > If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port Agreed, but you originally said you can disable IME, and that's all I was really taking issue with :) Disabling AMT still leaves IME: what is it doing? You don't know, and we'll never tell you ;) > Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do. Agreed. :( Thank you for the interesting discussion! It'd be fun to relax and argue about it sometime in person. :)