3 ms·
In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. If you don't have such a
by Sanddancer 10y ago
In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. If you don't have such a network interface, the ME can't do all that much, and any adverse security risks are near zero. Add to that things like the firmware write line being controlled by a completely separate microcontroller, and the big things that are discussed are completely infeasible. I'd be much more worried about the lack of microcode updates that libreboot users shun in the name of "freedom".
- Karunamon 10y agoIn order for the Management Engine to really do much, you... ...have to trust Intel's publicly available documentation. In other words, this has to be taken on pure faith that it does exactly what they say it does in exactly the way they say it does it, and no more. The problem with ME is that it consists of unauditable code that could be doing literally anything on the computer, completely transparent to the user. Furthermore, even if there is nothing untoward happening when the chip leaves the fab (again, must be taken on faith), a documented threat is having hardware interdicted, modified, and sent on its way.
- Sanddancer 10y agoInterdiction could happen with open source hardware too. Swipe the SoC, and no one would be the wiser. Given everything that has to be in place for vPro/the ME to work, looking at the pcb would give enough information to tell exactly how much, if any, information it could steal, if all the malicious items were in place. All of which could be easily undone by reflashing it, because the write line on the bios is not controlled by the CPU. A lot of steps have to be done, physically and in software in order to exploit it, and that exploit would melt away on the first bios flash. I'd be much more concerned about the security of the software running on the system than any theoretical hack on the ME.
- Karunamon 10y ago>Swipe the SoC, and no one would be the wiser. It would have to get swiped on the way from the manufacturer to the OEM. Once the OEM has sent it out, it's protected against this exact kind of attack. And while it may make sense for interdiction of a single package to a known target, doing the same with an entire batch of chips seems prohibitively expensive. >Given everything that has to be in place for vPro/the ME to work Again, per Intel's documentation. For all anyone here knows, data exfil begins the moment a certain sequence of bits crosses the right registers - and it's not like this is beyond the capabilities of what ME lets you do. There is no good reason that the entire subsystem can't be disabled by the user, permanently. But, come to find out about it, the chips are configured to shut the system down within 30 minutes if the ME firmware doesn't pass checksum. That, in my mind, puts it uncomfortably close to malware territory. Every one of these concerns evaporate if the ME area could be wiped or dumped - it's not as if remote management is some secret competitive advantage.
- Sanddancer 10y agoNo, this is not per the documentation, this is per the physical specifications, the circuitry that needs to be in place, the support that needs to be in each component. The Management Engine is not as all-seeing as you make it out to be.
- bwindels 10y agoFirst time I hear this. Can you elaborate or give a source for this?
- Karunamon 10y agoIt's all seeing enough to poll the installed system for info on installed software, to have keylogger rootkits installed in it, and so on. This is all per the (exhaustively sourced) Wiki article. The point I'm trying to convey here is that every piece of information available on this thing comes straight from the horse's mouth, and the horse is not necessarily a trustworthy actor.
- Foxboron 10y agoAccording to their documentation, the network module is "Intel Wireless Module". I assume Intel ME know how to talk to this one? https://www.orwl.org/wiki/images/9/95/SowDESIGN-SHIFTORWLPUBLIC20160902.pdf https://www.orwl.org/wiki/images/9/95/SowDESIGN-SHIFTORWLPUB...
- Sanddancer 10y agoOnly for the m7, because they enable vPro there. For the m3, vPro's not available, so the management engine won't be able to talk to the network card. Alternatively, you could just plug in your own USB wifi device, because it definitely wouldn't have the components for vPro to work.
- nickpsecurity 10y ago"In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. " For both ME and debugging purposes, Intel's chips are wired through and through in ways that could do interesting things in the hands of an attacker. ME gives attacker the ability to act. What you just said is you believe Intel's technical statements and marketing claims about that. In reality, you can't know about any digital, analog, or RF backdoors it creates unless you get whole thing torn down at transistor level with analysis by people who understand all those categories. It's normal in ASIC work, for trade secret protection and dodging patent suits, for firms to use tricks to hide I.P. in I.P.. They also reduce NRE & mask costs by putting circuitry in whole families of product while only visibly enabling them in some at factory. Still there, though. The guy that originally taught me about this stuff gave an example where one component they used had wireless connectivity because it was a mobile SOC where they visibly, but only temporarily, disabled some components to make it look like a microcontroller and I/O combo. They were trying to score extra ROI off it without building dedicated product. Lots of stuff like that in ASIC design. Hell, the firewall industry should've already taught all of you this lesson. Grimes reviews of them showed they often had all kinds of undocumented stuff running that wasn't advertised but was result of poor quality or some internal benefit. He rarely ran into one that did what it advertised and only what it advertised. That wasn't even open-source testing. ;) Intel's stuff is a combo of their specs, their implementation, the analog circuits, the effects of the materials involved on those, and the interactions with other things on the board if you're talking EMSEC. There's no way for you to verify these are secure by reading their public claims. This is neither a new nor uncommon problem.