Intel and ME, and why we should get rid of ME(fsf.org)
fsf.org
Intel and ME, and why we should get rid of ME
http://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me
153 comments
What kind of authentication is performed? What's stopping anyone on your network from performing the procedure described on any given machine? This is a worrisome development.
You can disable the remote management and the entire embedded network stack though.
That's not so easy to do. To get a sense of what's required...
https://software.intel.com/en-us/forums/intel-business-clien...
Plus, even you disable it there's still room for exploits, previous versions of Intel AMT have had exploits. Check out the 'Known vulnerabilities and exploits' section of the Intel AMT Wikipedia page:
https://en.m.wikipedia.org/wiki/Intel_Active_Management_Tech...
https://software.intel.com/en-us/forums/intel-business-clien...
Plus, even you disable it there's still room for exploits, previous versions of Intel AMT have had exploits. Check out the 'Known vulnerabilities and exploits' section of the Intel AMT Wikipedia page:
https://en.m.wikipedia.org/wiki/Intel_Active_Management_Tech...
Enabling it isn't generally easier either, and it can be secured with certificates on both side. Every time this topic is brought up I'm surprised by the number of people who think remote access is bad and cannot possibly be secured, while not actually digging into what it would take to compromise such a machine.
Maybe it's the server admin in me, but OOB BIOS-level remote access and management for my systems is a godsend and my biggest issue with it is that they tend not to include those features in their "enthusiast" chipsets.
Maybe it's the server admin in me, but OOB BIOS-level remote access and management for my systems is a godsend and my biggest issue with it is that they tend not to include those features in their "enthusiast" chipsets.
The security expert in me is terrified at the concept of remote access that, far too often, isn't actually managed very well. I've been to far too many places that have management interfaces like this and either don't know it, or don't apply updates.
It's not that remote access is bad, it's that all the remote access I've seen has been horrible. Hash disclosure is just seen as "meh, that's the way it is", and being able to login without a password is standard unless the IT has taken the time to update something they often don't even know about.
It's not that remote access is bad, it's that all the remote access I've seen has been horrible. Hash disclosure is just seen as "meh, that's the way it is", and being able to login without a password is standard unless the IT has taken the time to update something they often don't even know about.
The features are included in all modern Intel CPUs AFAIK, if you found one where it wasn't included please let me know as its absence would be a feature for me.
As for the number of people who think remote access is bad, nobody seems to be denying it can be useful, but by baking it into hardware you're basically hoping that it doesn't get hacked. If it was an optional dongle nobody would care.
As for the number of people who think remote access is bad, nobody seems to be denying it can be useful, but by baking it into hardware you're basically hoping that it doesn't get hacked. If it was an optional dongle nobody would care.
The remote access part is called AMT[1] and is part of the Intel vPro[2] feature set. It most certainly is not enabled in all modern Intel processors. Further, it requires a compatible processor, chipset, and BIOS for it to be enabled.
There is a common misunderstanding in these discussions that the ME features of the Intel processor (included in nearly all modern procs) allows for hardware level remote access, which isn't true.
[1] https://en.wikipedia.org/wiki/Intel_Active_Management_Techno... [2] https://en.wikipedia.org/wiki/Intel_vPro
There is a common misunderstanding in these discussions that the ME features of the Intel processor (included in nearly all modern procs) allows for hardware level remote access, which isn't true.
[1] https://en.wikipedia.org/wiki/Intel_Active_Management_Techno... [2] https://en.wikipedia.org/wiki/Intel_vPro
Yeah, right. I suppose we're just supposed to take their word for that. There's an enormous difference between the concepts of trusted and trustworthy. You're extremely naive or clearly never read anything Snowden released if you think 'trust us' is enough.
Are you suggesting Intel has implemented hidden backdoors into all of their systems?
Not OP but it could be very much possible and that's what OP is trying to say. Just taking it on Intel's word that they haven't done it is not the correct way to go. For the truly privacy minded, it's better to err on the side of caution.
Err on the side of caution in this sense would mean fabricating your own proc. Are you going to do that?
How do you know the fab you send your design to doesn't implement a backdoor? You have to have trust at SOME level.
How do you know the fab you send your design to doesn't implement a backdoor?
It really wouldn't be that hard to compare what you received from the foundry with the masks you sent them. There are services that decap ICs and attempt to reverse engineer them. Here's the first hit I found on Google: http://www.intelligservices.com/Services.htm
You wouldn't need the reverse engineering. All you would need to do is to compare that all the metal layers (and perhaps poly) match what you sent. That's an almost trivial comparison. The hard part of reverse engineering is in figuring out what the circuitry actually does, and you already know that, since it's your chip!
It could be possible for a fab to alter diffusion layers to change the functionality of a chip. That would be harder to detect by services such as the one I mentioned. But it would be very hard, very time consuming, to attempt to hack in a backdoor by only messing with base layers, rather than messing with metal or with poly (where changes are easily observed).
If there were to be a backdoor anywhere in a design, it would be in IP you used on your chip, that you got from either your foundry or from a 3rd party IP supplier. It would be easy enough to hide all kinds of stuff there.
It really wouldn't be that hard to compare what you received from the foundry with the masks you sent them. There are services that decap ICs and attempt to reverse engineer them. Here's the first hit I found on Google: http://www.intelligservices.com/Services.htm
You wouldn't need the reverse engineering. All you would need to do is to compare that all the metal layers (and perhaps poly) match what you sent. That's an almost trivial comparison. The hard part of reverse engineering is in figuring out what the circuitry actually does, and you already know that, since it's your chip!
It could be possible for a fab to alter diffusion layers to change the functionality of a chip. That would be harder to detect by services such as the one I mentioned. But it would be very hard, very time consuming, to attempt to hack in a backdoor by only messing with base layers, rather than messing with metal or with poly (where changes are easily observed).
If there were to be a backdoor anywhere in a design, it would be in IP you used on your chip, that you got from either your foundry or from a 3rd party IP supplier. It would be easy enough to hide all kinds of stuff there.
That is exactly my point. If you don't trust Intel, then who are you suggesting should build your processor? Unless you are going to design and fabricate your entire system top to bottom, and have no other persons involved who could surreptitiously insert evil code, then you're going to have to accept some degree of trust in a 3rd party.
AMT is full of holes too: http://people.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-...
From what I've seen, Intel ME is the set of CPU features that supports applications such as Intel AMT. As Intel ME is built into all modern x86/x64 Intel CPUs, the possibility for exploiting Intel ME is still a security issue, even if some features aren't enabled by default.
To put it another way, what are some of the details that the author(s) of this article got wrong?
https://libreboot.org/faq/#intel
To put it another way, what are some of the details that the author(s) of this article got wrong?
https://libreboot.org/faq/#intel
None, but you are taking away from it things that the article doesn't say. AMT is a subset of ME, it's not available on all procs, and even if it is available, it also requires the supporting chipset.
Nearly everyone reading this on a laptop/desktop system is doing so on an Intel processor. Go ahead and attempt to enable remote access without a supported proc/chipset/bios and then come back and complain about this unexpected remote access.
There is a lot of misunderstanding about this technology in the security world which strikes me odd because it's well-documented and readily available for your own testing.
Nearly everyone reading this on a laptop/desktop system is doing so on an Intel processor. Go ahead and attempt to enable remote access without a supported proc/chipset/bios and then come back and complain about this unexpected remote access.
There is a lot of misunderstanding about this technology in the security world which strikes me odd because it's well-documented and readily available for your own testing.
True enough. But as I mentioned, I was rather terrified when I tried this on my thinkpad laptop. I'm sure many other business laptops have similar facilities (and yes, of course it is a feature to be able to manage a large fleet of machines, both work stations and servers).
As for trust, first, what we generally know is that any complex system is likely to have flaws. So any remote access system is likely a back door - intentionally or not. A physical off switch would be prudent (arguably switching off wireless network card and not connecting an ethernet cable is one option: but then your options are: no networking or possible vulnerability).
It's not as if any networked machine is "perfectly secure" - but it'd be nice to be able to set the scope of exposure even more easily, and granularly.
Second, one thing is trusting Intel to not intentionally install a back-door - keeping in mind that includes any "golden key" for updates. And not leaving any holes in the interface they expose (ie:getting the feature right). That in itself is a pretty high bar, imnho. But another thing is trusting Intel not to build in secret backdoors - that is; if they say, no, there's no IME in product X, then trust them on that. That is to me a much more trivial thing to trust. I know there will be bugs in the software and hardware, but I'm not all that afraid of maliciousness.
If I was working for a Chinese intelligence service the threat model might have been different.
In sum, given that there's bound to be bugs, and might be well-intentioned software upgrade support - I would prefer if it was easier to buy high-end parts without stuff like IME (this also applies to AMD btw) - or at least that it was easy to remove a jumper or toggle a dip switch to turn the stuff completely off.
[ed: finally re: server Vs laptop: there are some things that doesn't matter as much if it's exposed on a server: got my encrypted backups? Encrypted email? No problem. Got my secret key from my laptop? that is a problem]
As for trust, first, what we generally know is that any complex system is likely to have flaws. So any remote access system is likely a back door - intentionally or not. A physical off switch would be prudent (arguably switching off wireless network card and not connecting an ethernet cable is one option: but then your options are: no networking or possible vulnerability).
It's not as if any networked machine is "perfectly secure" - but it'd be nice to be able to set the scope of exposure even more easily, and granularly.
Second, one thing is trusting Intel to not intentionally install a back-door - keeping in mind that includes any "golden key" for updates. And not leaving any holes in the interface they expose (ie:getting the feature right). That in itself is a pretty high bar, imnho. But another thing is trusting Intel not to build in secret backdoors - that is; if they say, no, there's no IME in product X, then trust them on that. That is to me a much more trivial thing to trust. I know there will be bugs in the software and hardware, but I'm not all that afraid of maliciousness.
If I was working for a Chinese intelligence service the threat model might have been different.
In sum, given that there's bound to be bugs, and might be well-intentioned software upgrade support - I would prefer if it was easier to buy high-end parts without stuff like IME (this also applies to AMD btw) - or at least that it was easy to remove a jumper or toggle a dip switch to turn the stuff completely off.
[ed: finally re: server Vs laptop: there are some things that doesn't matter as much if it's exposed on a server: got my encrypted backups? Encrypted email? No problem. Got my secret key from my laptop? that is a problem]
Exactly.
Optional, hardware mediated remote access is good.
Optional, hardware mediated remote access is good.
[deleted]
TL;DR: Build yourself a desktop with a non-vPro CPU and a non-Intel NIC. Check [0] for a list of such CPUs.
The usual recommendation is to either get a pre-2009 AMD machine (which is what my present desktop is) or get a Sparc machine. My boss won't buy me a desktop with an UltraSparc CPU, so I won't bother with that. AMD has substantially less documentation than Intel, AFAICT, so Intel products deserve investigation for their relative starkness.
An albeit outdate list of systems to avoid, see [1].
I will assume that you are trying to build a desktop from off-the-shelf parts.
For sure, get a CPU without vPro, since that downgrades the type of AMT/IME feature set to Standard Manageability:
"Please note that NON -vPro™ Intel® desktop procesors will make Intel® ME FW to switch its features set from full Intel® Active Management Technology to Intel® Standard Manageability that do not suport Intel® AMT KVM Redirection feature (it is disabled internally in the Intel® ME FW)." [2] When the CPU doesn't support AMT, then Standard Manageability is what is running in the background.
This says 2 things: (1) non-vPro desktop CPUs downgrade AMT to Standard Manageability and (2) IME is active regardless of the CPU's feature set.
What is Intel Standard Manageability? "Q8: What is Intel® Standard Manageability and can it run on a non-Intel® vPro™ technology-based CPU? A8: Some basic management capabilities are available on non-Intel® vPro™ technology-eligible Intel® Core™2 processors as well as Intel® Pentium® dual-core and Intel® Celeron® processor-based CPUs. Intel® Standard Manageability is available only on desktop systems right now (not notebook), and only includes basic capabilities such as hardware and software inventory and remote diagnostics." [3]
I can't tell if Standard Manageability is a lite version of AMT. Intel's documentation on it [4] isn't a whole lot of help.
Intel mentions that Atom and i3 platforms generally do not support AMT. [5]
At the bottom of this [6] page lists those Intel chipsets with IME. I'd consider that to be a list of chipsets to avoid, but those cover almost all modern chipsets, AFAIK.
For sure, don't use any Intel NICs: "Adding another NIC will not nullify Intel® vPro™ technology verification, but Intel® Active Management Technology communicates only through the onboard network interface of Intel vPro technology, and it is strongly recommended that an additional wired NIC is not added to the platform as this might cause some of the features of Intel AMT to not operate as expected." [7]
[0] = http://ark.intel.com/search/advanced?s=t&VProTechnology=fals...
[1] = https://communities.intel.com/docs/DOC-2033
[2] = https://communities.intel.com/thread/65350
[3] = https://software.intel.com/en-us/articles/intel-vpro-technol...
[4] = https://software.intel.com/en-us/blogs/2009/03/27/what-is-st...
[5] = http://www.intel.com/content/dam/www/public/us/en/include/re...
[6] = https://www.kernel.org/doc/Documentation/misc-devices/mei/me...
[7] = https://software.intel.com/en-us/articles/intel-vpro-technol...
The usual recommendation is to either get a pre-2009 AMD machine (which is what my present desktop is) or get a Sparc machine. My boss won't buy me a desktop with an UltraSparc CPU, so I won't bother with that. AMD has substantially less documentation than Intel, AFAICT, so Intel products deserve investigation for their relative starkness.
An albeit outdate list of systems to avoid, see [1].
I will assume that you are trying to build a desktop from off-the-shelf parts.
For sure, get a CPU without vPro, since that downgrades the type of AMT/IME feature set to Standard Manageability:
"Please note that NON -vPro™ Intel® desktop procesors will make Intel® ME FW to switch its features set from full Intel® Active Management Technology to Intel® Standard Manageability that do not suport Intel® AMT KVM Redirection feature (it is disabled internally in the Intel® ME FW)." [2] When the CPU doesn't support AMT, then Standard Manageability is what is running in the background.
This says 2 things: (1) non-vPro desktop CPUs downgrade AMT to Standard Manageability and (2) IME is active regardless of the CPU's feature set.
What is Intel Standard Manageability? "Q8: What is Intel® Standard Manageability and can it run on a non-Intel® vPro™ technology-based CPU? A8: Some basic management capabilities are available on non-Intel® vPro™ technology-eligible Intel® Core™2 processors as well as Intel® Pentium® dual-core and Intel® Celeron® processor-based CPUs. Intel® Standard Manageability is available only on desktop systems right now (not notebook), and only includes basic capabilities such as hardware and software inventory and remote diagnostics." [3]
I can't tell if Standard Manageability is a lite version of AMT. Intel's documentation on it [4] isn't a whole lot of help.
Intel mentions that Atom and i3 platforms generally do not support AMT. [5]
At the bottom of this [6] page lists those Intel chipsets with IME. I'd consider that to be a list of chipsets to avoid, but those cover almost all modern chipsets, AFAIK.
For sure, don't use any Intel NICs: "Adding another NIC will not nullify Intel® vPro™ technology verification, but Intel® Active Management Technology communicates only through the onboard network interface of Intel vPro technology, and it is strongly recommended that an additional wired NIC is not added to the platform as this might cause some of the features of Intel AMT to not operate as expected." [7]
[0] = http://ark.intel.com/search/advanced?s=t&VProTechnology=fals...
[1] = https://communities.intel.com/docs/DOC-2033
[2] = https://communities.intel.com/thread/65350
[3] = https://software.intel.com/en-us/articles/intel-vpro-technol...
[4] = https://software.intel.com/en-us/blogs/2009/03/27/what-is-st...
[5] = http://www.intel.com/content/dam/www/public/us/en/include/re...
[6] = https://www.kernel.org/doc/Documentation/misc-devices/mei/me...
[7] = https://software.intel.com/en-us/articles/intel-vpro-technol...
Can you enumerate "enthusiast" chipsets?
I'd like to know what chipset to choose in the future.
Thanks.
I'd like to know what chipset to choose in the future.
Thanks.
Yeah, I find it difficult to understand the hoopla around IME. It's not much different from the BMC that's on pretty much all server hardware.
Let me make this totally clear. The top OEM hardware manufacturers couldn't give a CRAP about your security.
https://duo.com/blog/out-of-box-exploitation-a-security-anal...
e.g. http://teletext.zaibatsutel.net/post/145370716258/deadupdate...
But you're totally fine that THESE are the people with unfetted power to fill your system with backdoors? (Not to mention NSA etc who'd almost certainly have access).
What's wrong with you having zero care about the world's data security?
https://duo.com/blog/out-of-box-exploitation-a-security-anal...
e.g. http://teletext.zaibatsutel.net/post/145370716258/deadupdate...
But you're totally fine that THESE are the people with unfetted power to fill your system with backdoors? (Not to mention NSA etc who'd almost certainly have access).
What's wrong with you having zero care about the world's data security?
It's not so much that I don't care, more that it's nothing new.
I just don't understand why people are suddenly railing against IME instead of Dell, SuperMicro, HP, etc when there is far more hardware out there with far, far less secure BMCs and it's been that way for ages. IME is probably closer to the best of the bunch as far as security goes.
I just don't understand why people are suddenly railing against IME instead of Dell, SuperMicro, HP, etc when there is far more hardware out there with far, far less secure BMCs and it's been that way for ages. IME is probably closer to the best of the bunch as far as security goes.
IME is horrible and we should be railing against all horrible implementations. I can assure you I let my OEM know full well how I felt about insecure automatic update software (even though I wipe the system as soon as I get it, something I can't do with ME). I'll be taking my next purchase elsewhere. Unless people speak up, it's guaranteed to only gets worse.
I think we're talking about two different things. BMCs run separately from the rest of the system and are active even when the machine is halted. They provide remote mouse/keyboard/monitor, power control, remote device mounting, bios settings, hardware sensors and monitoring, etc. These have been in servers for ages, do the same thing as IME, and are way less secure. None of it has any relevance to software updaters or software at all really since a lot of these boxes are shipped without an OS or even hard drives.
I followed what you meant and understand baseband management controllers are more similar to IME in terms of risk profile. They're not (generally?) on-chip though, so it's at least up to individual OEMs, and purchasers have slightly more options (if slim). Agree it's not widely enough recognised either though. There's some coverage at least:
https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+... http://arstechnica.com/security/2013/08/remote-admin-tool-im... https://www.usenix.org/system/files/conference/woot13/woot13... https://community.rapid7.com/community/metasploit/blog/2013/... https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... http://www.websecuritywatch.com/authentication-bypass-vulner... http://fish2.com/ipmi/itrain.pdf
https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+... http://arstechnica.com/security/2013/08/remote-admin-tool-im... https://www.usenix.org/system/files/conference/woot13/woot13... https://community.rapid7.com/community/metasploit/blog/2013/... https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... http://www.websecuritywatch.com/authentication-bypass-vulner... http://fish2.com/ipmi/itrain.pdf
The horrible GUIs are just icing on the cake. It doesn't even take that much to design a passable GUI.
[deleted]
Wow, no one here has mentioned Johanna Rutkovska's (Invisible Things Lab & QubesOS), "Intel x86 Considered Harmful"?
http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Essential reading!!
https://www.youtube.com/watch?v=rcwngbUrZNg
http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Essential reading!!
https://www.youtube.com/watch?v=rcwngbUrZNg
Joanna is a hero.
Also, I would give anything for a clean slate design that prioritized simplicity and transparency.
We've been layering complicated crap under and on top of older complicated crap for so long that even professional engineers no longer understand exactly what happens when you push the power button.
As long as that is true, we will never be secure.
Also, I would give anything for a clean slate design that prioritized simplicity and transparency.
We've been layering complicated crap under and on top of older complicated crap for so long that even professional engineers no longer understand exactly what happens when you push the power button.
As long as that is true, we will never be secure.
Totally agree. She's brilliant. Deepest respect to her.
One of the extremely few people with genuine understanding of hardware security, who's working on the side of users & humanity.
The first time I read her work, I was floored that I hadn't known of her earlier.
One of the extremely few people with genuine understanding of hardware security, who's working on the side of users & humanity.
The first time I read her work, I was floored that I hadn't known of her earlier.
Seriously, watch this ^. It's pretty much the canonical coverage of the topic.
There was another thread on ME. At some point ME will get hacked or the golden certificate stolen, at which point someone will have a lot of access.
https://news.ycombinator.com/item?id=8813029
https://news.ycombinator.com/item?id=8813029
> My first thought was that it seems increasingly clear that Stallman has been right all along.
The problem is that being philosophically right doesn't always mean being practically right. In order to create the perfect Stallman-esque machine, one would have to design everything from the logic chips up from scratch, because in the end, no third party can be trusted. He says this himself about the Loongson system he uses daily; he considers it a compromise but one heavily weighted in his favor.
In short, Stallman has been right all along, but there's little we can do about it from a practical standpoint.
Cherry-picked from that thread. I just have to point out this awful slippery-slope argument.
Cherry-picked from that thread. I just have to point out this awful slippery-slope argument.
Just because we list slippery slope as a fallacy, does not mean it never happens like that.
Basically Intel owns the desktop and server market. They sneak stuff in that we may not want. What can we do at this point?
Basically Intel owns the desktop and server market. They sneak stuff in that we may not want. What can we do at this point?
Vocally support Power8 and RISC-V projects and ensure Intel knows you're angry.
Like what happened with the NSA? Not to be rude, but you can be vocal all you want, but as long as the majority of the public doesn't care, there's not much you can do.
I don't think being vocal is enough. Snowden was vocal. What has changed?
Divest.
Or some government(s) will convince, legally force, or clandestinely steal the key. I'd put the US and China at the top of the list of governments that have probably already done it...heck, ME might be a backdoor deliberately created at the US government's behest.
I hope these guys get lots of orders and prices fall (Raptor's Talos Secure Workstation): https://www.raptorengineering.com/TALOS/prerelease.php
With Google having ported all their software to Power8, I'm looking forward to more economies of scale kicking on.
With Google having ported all their software to Power8, I'm looking forward to more economies of scale kicking on.
I hope they get sufficient preorders so they can start manufacturing it.
I currently have a 125W TDP AMD processor with "just" 8 cores, looking forward to a Power8 workstation that should have 64 logical CPU cores at 130W TDP [1] and avoids the Intel ME/AMD PSP trap.
[1] https://www.raptorengineering.com/TALOS/faq.php
I currently have a 125W TDP AMD processor with "just" 8 cores, looking forward to a Power8 workstation that should have 64 logical CPU cores at 130W TDP [1] and avoids the Intel ME/AMD PSP trap.
[1] https://www.raptorengineering.com/TALOS/faq.php
It looks great, except it has a ASpeed AST2400 BMC on the board which seems to do video and usb over IP etc (edit: eg it ties into networking, pci, usb, memory)...
Unless the firmware running on the BMC is going to be open source, I fail to see how it helps.
Unless the firmware running on the BMC is going to be open source, I fail to see how it helps.
Does this cover your concerns?
Open-toolchain FPGAs
Blob-free operation
- Fully libre (open-source) IBM OPAL primary firmware w/ PetitBoot interface
- Fully libre (open-source) OpenBMC secondary (IPMI / OoBM) firmware
NO signing keys preventing firmware modificationGets most of the way there, though I'm confused as to the wording on the BSC. "Fully libre OpenBMC _secondary_ firmware". Still slightly worried as to the meaning of Secondary firmware; almost makes me think the BSC has non-libre _primary_ firmware on there too.
FWIW, there is a petition for Intel to Release an ME-less CPU design: https://puri.sm/posts/petition-for-intel-to-release-an-me-le...
I don't see how getting rid of the ME helps. If you don't trust Intel then you don't trust Intel. They can backdoor the main CPU as easily as they can backdoor the ME. The only true solution is an Open Source Hardware CPU, and some means of verifying that the hardware matches the HDL.
There are already Open Source CPU designs, but the verification is more difficult. Even if you use a big enough process node that you can decap it and inspect it optically (eg. using similar techniques as used with http://visual6502.org/ ), there is still the possibility of dopant-level backdoors which are much harder to detect:
http://sharps.org/wp-content/uploads/BECKER-CHES.pdf
There are already Open Source CPU designs, but the verification is more difficult. Even if you use a big enough process node that you can decap it and inspect it optically (eg. using similar techniques as used with http://visual6502.org/ ), there is still the possibility of dopant-level backdoors which are much harder to detect:
http://sharps.org/wp-content/uploads/BECKER-CHES.pdf
> I don't see how getting rid of the ME helps. If you don't trust Intel then you don't trust Intel.
As dandelion_lover says, security is not boolean.
I may or I may not trust Intel to backdoor the processor I run code of my choice on in more or less visible ways (the more visible, the more risk of public opinion backlash if it is revealed what Intel did), but I absolutely do not trust Intel and its business partners to design an independent subsystem that runs their code and is not vulnerable to Intel (or any rogue employee thereof) + Intel's business partners (or any rogue employee thereof) + US federal entities (or any rogue employee thereof) that can coerce any large or small US company.
I am not suspecting Intel of ill intent. I am suspecting Intel and its partners of incompetence. There is a big difference. Intel can not actually “backdoor the main CPU as easily as” they can leave the ME open to attacks. The second one is so easy that you might as well assume it is the case until convincing arguments have shown otherwise.
As dandelion_lover says, security is not boolean.
I may or I may not trust Intel to backdoor the processor I run code of my choice on in more or less visible ways (the more visible, the more risk of public opinion backlash if it is revealed what Intel did), but I absolutely do not trust Intel and its business partners to design an independent subsystem that runs their code and is not vulnerable to Intel (or any rogue employee thereof) + Intel's business partners (or any rogue employee thereof) + US federal entities (or any rogue employee thereof) that can coerce any large or small US company.
I am not suspecting Intel of ill intent. I am suspecting Intel and its partners of incompetence. There is a big difference. Intel can not actually “backdoor the main CPU as easily as” they can leave the ME open to attacks. The second one is so easy that you might as well assume it is the case until convincing arguments have shown otherwise.
Trusting Intel on producing a CPU, and trusting Intel with ME are completely different levels of trust.
If I could run my own software on the Intel ME, I wouldn't mind.
In some sense having Intel ME is worse than having Windows as your OS: at least you can apply security patches for Windows, and should you choose to do so you can replace it with your favourite OS. However Intel ME is entirely closed source and locked down: probably running out-of-date software with several unpatched vulnerabilities with no way for the user to inspect it, patch it, turn it off with a jumper or replace it.
In some sense having Intel ME is worse than having Windows as your OS: at least you can apply security patches for Windows, and should you choose to do so you can replace it with your favourite OS. However Intel ME is entirely closed source and locked down: probably running out-of-date software with several unpatched vulnerabilities with no way for the user to inspect it, patch it, turn it off with a jumper or replace it.
AFAIK they can patch the Intel ME firmware and often do with BIOS updates. I am not sure about AMD PSP but that don't have access to the network so patching it is less important.
>If you don't trust Intel then you don't trust Intel.
Security is not a boolean. It's a price to own you. By removing Intel ME you increase this price.
Security is not a boolean. It's a price to own you. By removing Intel ME you increase this price.
RISC-V architectures hold the most promise there AFAIAA.
BSD-licensed, cutting-edge architecture and it's got the right backers.
FreeBSD is already ported to it. There'll be a range silicon implementations. Cambridge's lowRISC is likely to be the first SoC, with design completing this year.
BSD-licensed, cutting-edge architecture and it's got the right backers.
FreeBSD is already ported to it. There'll be a range silicon implementations. Cambridge's lowRISC is likely to be the first SoC, with design completing this year.
The backers will probably be making proprietary implementations with ME-style backdoors.
No doubt some of the bigger ones probably will. When it's BSD (not bound by restrictive commercial licensing agreements) though, it massively lowers the barriers to entry for manufacturers who will offer security.
Anyway, here's an entirely open source one you can inspect: http://www.lowrisc.org/. Put it on an FPGA if you want.
Anyway, here's an entirely open source one you can inspect: http://www.lowrisc.org/. Put it on an FPGA if you want.
The problem with ME is that enables a number of additional attacks, even if it's not backdoored.
I often wonder if the only secure computing and communication these days is an air-gapped computer.
The data can be manipulated there and then copied to another computer using... uh... a writeable compact disk? USB drives are hard to trust given how much software is running on them, so... maybe CF cards too?
The data can be manipulated there and then copied to another computer using... uh... a writeable compact disk? USB drives are hard to trust given how much software is running on them, so... maybe CF cards too?
You want data diodes that physically enforce one-way-only data transfer.
Tin Foil Chat[1] has a circuit for an opto-isolator based data diode and a discussion of how to use them for secure chat. It's probably not hard to modify these plans for other uses, if the specific guarantees that TFC provides are compatible with your secure computing requirements.
[1] https://cs.helsinki.fi/u/oottela/tfc.pdf
Tin Foil Chat[1] has a circuit for an opto-isolator based data diode and a discussion of how to use them for secure chat. It's probably not hard to modify these plans for other uses, if the specific guarantees that TFC provides are compatible with your secure computing requirements.
[1] https://cs.helsinki.fi/u/oottela/tfc.pdf
It's not hard to adapt. He regularly improved it based on our feedback at Schneier's blog. I speculated that a higher bandwidth would allow audio and video using same architecture. It's a great desigm regardless due yo strong confidentiality despite endpoint attacks.
Very interesting... so one machine for sending data (one-way channel) and another machine fro receiving data (also a one-way channel). That, in combination with a one-way serial port, might just suffice.
Routing the data through a central IM server is a huge problem, it would still allow one to figure out who is talking to who and when.
>I often wonder if the only secure computing and communication these days is an air-gapped computer.
Some security experts say air-gapping is not the best approach. Consider Qubes OS instead.
"How does Qubes OS compare to using a separate physical machine?", https://www.qubes-os.org/tour/
Some security experts say air-gapping is not the best approach. Consider Qubes OS instead.
"How does Qubes OS compare to using a separate physical machine?", https://www.qubes-os.org/tour/
None of that will help if the on-chip (CPU) code is hostile. Once the CPU itself is compromised, preventing connections is the only way to contain the problem.
Install a VM on an air-gapped computer, use a guest OS to zip & encrypt the data you want to transfer, dump that zip on a disc, and unpack/decrypt it inside another VM on the destination computer?
Outgoing, secret data plus incoming, malicious data sharing hardware is where security problems start. Ottela keeps those separate physically. Prevents many types of attack or unnecessary complexity.
Scary, I did not know this
I'm sure Intel has a real good reason for it being there but I would feel much more comfortable with it either not being there or being able to disable it in hardware.
I'm sure Intel has a real good reason for it being there but I would feel much more comfortable with it either not being there or being able to disable it in hardware.
Just wanted to point out that there is a petition to release a ME less CPU: https://puri.sm/posts/petition-for-intel-to-release-an-me-le...
Doubt that will change anything (willingness, price for probably new masks etc. etc.) but it would certainly be nice.
Doubt that will change anything (willingness, price for probably new masks etc. etc.) but it would certainly be nice.
I'm entirely convinced that Intel would undermine the entire trusted computer over some relatively hairbrained ideas about new revenue sources.
Intel needs to give us an alternative.
Intel needs to give us an alternative.
I'm not sure what that “good reason” could possibly be.
It's known to be used for DRM.¹ So… not a good reason, but at least it makes sense. Then there's Intel's very likely cozy relationship with the NSA.² ³ ⁴ ⁵
--
¹ https://libreboot.org/faq/#intelme See paragraph 6.
² https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
³ http://www.eteknix.com/expert-says-nsa-have-backdoors-built-...
⁴ http://www.infowars.com/intel-ceo-refuses-to-answer-question... (Note the NSA slide.)
⁵ https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_b... (No hard evidence, but he dodged basically every question related to the NSA.)
--
¹ https://libreboot.org/faq/#intelme See paragraph 6.
² https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
³ http://www.eteknix.com/expert-says-nsa-have-backdoors-built-...
⁴ http://www.infowars.com/intel-ceo-refuses-to-answer-question... (Note the NSA slide.)
⁵ https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_b... (No hard evidence, but he dodged basically every question related to the NSA.)
> It's known to be used for DRM.
Better citation needed. AFAIK the ME has never been used for DRM. It's supposedly used to implement TPM 2.0 aka PTT, but AFAIK that has never been used for DRM either.
Better citation needed. AFAIK the ME has never been used for DRM. It's supposedly used to implement TPM 2.0 aka PTT, but AFAIK that has never been used for DRM either.
PAVP (Protected Audio-Video Path, which has gone by other names), as described in the FAQ entry, is a real thing, albeit without any public documentation whatsoever other than acknowledging that it exists - implemented in ME and used by some commercial video DRM implementations. Not sure what kind of citation you want, but it's briefly mentioned in this presentation about reverse engineering ME:
https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
SGX is the other feature needed for DRM. Just read Intel's own documentation for SGX; it's all about creating a Trusted Computing environment, using the old Palladium/NGSCB sense of "trusted".
ME also controls the feature set available to the storage controller. I.E. whether or not it can support RAID 0, 1, 5 natively. Its features can be updated via BIOS firmware, which has to correspond to whats baked into the CPU. It can be bypassed using a special version of BIOS firmware in combination with a cpu with the right fuses blown. It almost takes an act of god to get all those things, even in their lab, when you're getting paid to test it.
Really? That surprises me.
AFAICT Intel's desktop RAID tech literally just remaps PCI vendor and device ids (which is a wee bit more complicated with NVMe / AHCI over SATA Express). The boot process was an option ROM and is presumably now baked into UEFI. The driver does the rest.
I can imagine that a couple bits in ME tell the UEFI blob and the driver which feature set to enable. Is there more?
AFAICT Intel's desktop RAID tech literally just remaps PCI vendor and device ids (which is a wee bit more complicated with NVMe / AHCI over SATA Express). The boot process was an option ROM and is presumably now baked into UEFI. The driver does the rest.
I can imagine that a couple bits in ME tell the UEFI blob and the driver which feature set to enable. Is there more?
Off topic: Your ¹²³ thing is really cool. Do you mind if I use it too?
Of course not, go for it. On Windows I use https://github.com/SamHocevar/wincompose to type that and a bunch of other useful characters. On FreeBSD and Linux, .XCompose.
How is that done?
In Emacs, this can be done using "C-\ TeX", which enables an input mode that turns ^1 (resp. _1) into a superscript (resp. subscript) 1, and similarly for other digits. (Hacker News' UI is simple enough to be usable in Emacs.) No idea about other environments.
Unicode superscript numbers
Also see http://text-symbols.com/upside-down/ :)
One of many implementations: http://www.upsidedowntext.com/
One of many implementations: http://www.upsidedowntext.com/
Well, having a KVM that one can use to remotely connect to their machines is a good reason (if we leave the statement at this level and assume that everything is done in the best interests of the end-users, by their informed demand).
For example, having IPMI with serial console access or a full-fledged VNC on HP iLO on servers proved to be really useful on different occasions, where I was able to fix the boot-level problems remotely rather than having to drive for an hour to visit the server.
Remote access is of less importance with desktops - and even less with laptops - as in most cases user is physically present, but still I had a few cases where I regretted not having a way to remotely connect to my machine at home (it had failed after a power outage), while I was on the road.
I'd say, the very core idea isn't really bad. Intel's implementation is terrible.
For example, having IPMI with serial console access or a full-fledged VNC on HP iLO on servers proved to be really useful on different occasions, where I was able to fix the boot-level problems remotely rather than having to drive for an hour to visit the server.
Remote access is of less importance with desktops - and even less with laptops - as in most cases user is physically present, but still I had a few cases where I regretted not having a way to remotely connect to my machine at home (it had failed after a power outage), while I was on the road.
I'd say, the very core idea isn't really bad. Intel's implementation is terrible.
If you want this there is no reason the software needs to be embedded in the hardware. Install a hypervisor with remote access, install the other OS in a VM and you have all the same capabilities through the hypervisor, but now you can inspect or improve the hypervisor and update it when it's vulnerable.
The whole point of a independent hardware KVM is that it's autonomous - no matter which state the software (and unrelated hardware) is in, you can still access the system and try to recover.
But, sure, I fully agree about the need of such system being an open platform that user can audit, update and control - rather than a black box. (Well, if there is a platform at all - a simplest external IP KVM could be a very dumb hardware box with the only software being an extremely primitive TCP/IP stack.)
Added: Anecdote: In early 2000s, some company I know of, had quite simplest remote access tools - DIY remote reboot devices made of externally-powered Realtek network cards. Sending a WoL packet to a known MAC (on a well-isolated network) would forcibly power-cycle the connected machine or router. No amount of fancy software solutions would bring a well-hung host back online. ;)
But, sure, I fully agree about the need of such system being an open platform that user can audit, update and control - rather than a black box. (Well, if there is a platform at all - a simplest external IP KVM could be a very dumb hardware box with the only software being an extremely primitive TCP/IP stack.)
Added: Anecdote: In early 2000s, some company I know of, had quite simplest remote access tools - DIY remote reboot devices made of externally-powered Realtek network cards. Sending a WoL packet to a known MAC (on a well-isolated network) would forcibly power-cycle the connected machine or router. No amount of fancy software solutions would bring a well-hung host back online. ;)
> The whole point of a independent hardware KVM is that it's autonomous
Which Intel ME isn't any more than a hypervisor is. It uses the same CPU and network interface and can be misconfigured in the same ways a hypervisor can. It essentially is a hypervisor but one that you can't remove or replace.
There are advantages to really independent hardware but firmware doesn't get you those, and there are advantages to management software but none of them require the software to be burned into the silicon. I agree that the feature set can be useful, it just doesn't belong where they put it (and in that sense we may only be arguing past each other).
Which Intel ME isn't any more than a hypervisor is. It uses the same CPU and network interface and can be misconfigured in the same ways a hypervisor can. It essentially is a hypervisor but one that you can't remove or replace.
There are advantages to really independent hardware but firmware doesn't get you those, and there are advantages to management software but none of them require the software to be burned into the silicon. I agree that the feature set can be useful, it just doesn't belong where they put it (and in that sense we may only be arguing past each other).
There's no hypervisor that'll let you power up a halted server, change bios settings, change boot device or order, boot the system of pxe, etc, etc. It's not the same thing at all, and almost every server made in the last decade has a BMC that gives you all the remote access features anyways, so getting IME isn't much of a change there.
> There's no hypervisor that'll let you power up a halted server, change bios settings, change boot device or order, boot the system of pxe, etc, etc.
Wake on LAN is a 20th century technology that requires no other privileges to implement and can be access controlled via managed switches. Pretty much every hypervisor will allow you to turn on a VM, change its boot device order or boot PXE and can change BIOS/firmware settings on any platform with an API to do that.
Wake on LAN is a 20th century technology that requires no other privileges to implement and can be access controlled via managed switches. Pretty much every hypervisor will allow you to turn on a VM, change its boot device order or boot PXE and can change BIOS/firmware settings on any platform with an API to do that.
Comparing Wake on LAN to a BMC is like comparing a text editor to an IDE. Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
> Comparing Wake on LAN to a BMC is like comparing a text editor to an IDE.
That's the point. If all you need is the ability to power on the machine, why are you exposing any more than that to the network?
> Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
And the party in control of that is Intel, so they could provide that API instead of IME.
That's the point. If all you need is the ability to power on the machine, why are you exposing any more than that to the network?
> Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
And the party in control of that is Intel, so they could provide that API instead of IME.
Yes, but BMCs do more than just power machines on and off, and are used for more than powering machines on and off. Automatic hardware provisioning fully depends on BMCs.
Intel is the party in control, and Dell, and Supermicro, and HP, and....
IPMI is the API you're looking for, you can always just shut off the networking. But again, it's still done through the BMC. SOMETHING has to do it, and that something needs access independent of the OS and the rest of the system due to the nature of the settings you can change.
Also how is IME any different than providing an API? The api has to actually do something, how exactly do you propose to do that without something like IME?
Intel is the party in control, and Dell, and Supermicro, and HP, and....
IPMI is the API you're looking for, you can always just shut off the networking. But again, it's still done through the BMC. SOMETHING has to do it, and that something needs access independent of the OS and the rest of the system due to the nature of the settings you can change.
Also how is IME any different than providing an API? The api has to actually do something, how exactly do you propose to do that without something like IME?
> Yes, but BMCs do more than just power machines on and off, and are used for more than powering machines on and off.
Turning on a powered-off machine is the only thing that couldn't be done by a hypervisor.
Once the machine is turned on, a hypervisor should be able to do anything IME does by doing it the same way IME does it, as long as the hardware is sufficiently documented.
The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
Turning on a powered-off machine is the only thing that couldn't be done by a hypervisor.
Once the machine is turned on, a hypervisor should be able to do anything IME does by doing it the same way IME does it, as long as the hardware is sufficiently documented.
The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
I don't have much of a need for this feature, but I see your point.
For Intel, it's a enterprise marketing bullet, for the rest of us it's an opportunity to secure our systems the way we want, however that capacity has been denied us.
The ideal security mechanism would provide us with a per cpu key from Intel, which we use to update our own user key to the cpu, and only user signed firmware is loaded.
The exact mechanism of this can be handled in many ways.
Right now, we locked out, and primed for being snooped on without our consent.
I like Intel's engineering, but everything else I could do without.
And ARM is no better. I'd say worse actually, but I'm not going to defend that.
Please, please, AMD do the "right thing" with Zen. Allow us to be in command of our security, so we may delegate it to those we trust with the technical know how, be it OS vendors, or our IT departments, or our own selves.
The ideal security mechanism would provide us with a per cpu key from Intel, which we use to update our own user key to the cpu, and only user signed firmware is loaded.
The exact mechanism of this can be handled in many ways.
Right now, we locked out, and primed for being snooped on without our consent.
I like Intel's engineering, but everything else I could do without.
And ARM is no better. I'd say worse actually, but I'm not going to defend that.
Please, please, AMD do the "right thing" with Zen. Allow us to be in command of our security, so we may delegate it to those we trust with the technical know how, be it OS vendors, or our IT departments, or our own selves.
USB Armory seems to be doing exactly what you ask for with ARM TrustZone. You own the SoC and can set your own master keys.
>Libreboot X200 laptop
Is this laptop the top of the line spec-wise that you can buy which is free from this trash?
Is this laptop the top of the line spec-wise that you can buy which is free from this trash?
Semi-hijacking your question to mention the other side of the pond too, which many people do not seem to know about and I run into this issue quite regularly.
While the laptop situation is indeed pretty bad (the X200 is probably as best as you can get here), for people looking for a modern workstation, AMD's current FX processor lineup is still free from this trash. Past the 2013 designs (Family 16h [1]) AMD includes their own equivalent of Intel's ME called PSP [2], so presumably the upcoming Zen is going to be heavily backdoored too.
Now, you can still buy an 8-core/4 GHz+ AMD Vishera [3] generation (which is the "current" FX), add a motherboard with ECC support (in a stark contrast to Intel, all AMD FX processors fully support ECC memory and for example ASUS sells a number of AMD motherboards with ECC support) and build yourself a workstation that will easily last for another decade, possibly longer (you can always buy a motherboard or two of your favourite model as a backup for the times when they finally disappear from the market). All FX processors are factory unlocked [4] and can be pushed much farther past their design specs with decent cooling, adding another bit to their possible usefulness over the long term.
Some more (random) reading on the subject of avoiding AMD PSP and Intel ME:
http://hollaforums.com/thread/557954/technology/uncorrectabl...
-
[1] - https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
[2] - https://libreboot.org/faq/#amd
[3] - https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors...
[4] - http://www.techpowerup.com/153445/amd-unlocked-fx-processors...
While the laptop situation is indeed pretty bad (the X200 is probably as best as you can get here), for people looking for a modern workstation, AMD's current FX processor lineup is still free from this trash. Past the 2013 designs (Family 16h [1]) AMD includes their own equivalent of Intel's ME called PSP [2], so presumably the upcoming Zen is going to be heavily backdoored too.
Now, you can still buy an 8-core/4 GHz+ AMD Vishera [3] generation (which is the "current" FX), add a motherboard with ECC support (in a stark contrast to Intel, all AMD FX processors fully support ECC memory and for example ASUS sells a number of AMD motherboards with ECC support) and build yourself a workstation that will easily last for another decade, possibly longer (you can always buy a motherboard or two of your favourite model as a backup for the times when they finally disappear from the market). All FX processors are factory unlocked [4] and can be pushed much farther past their design specs with decent cooling, adding another bit to their possible usefulness over the long term.
Some more (random) reading on the subject of avoiding AMD PSP and Intel ME:
http://hollaforums.com/thread/557954/technology/uncorrectabl...
-
[1] - https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
[2] - https://libreboot.org/faq/#amd
[3] - https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors...
[4] - http://www.techpowerup.com/153445/amd-unlocked-fx-processors...
I should also point out however that AMD PSP don't have access to the network.
Depends what you mean by "laptop". According to [1], the fastest processor that shipped with an X200 is the Intel T9600. Checking Geekbench, today's top-of-the-line 64-bit ARM phablets seem to have significantly higher CPU performance (both single and multi-core), and an equal amount of RAM. AFAIK, those devices don't have anything like Intel ME; they do typically have a hypervisor running above the Linux kernel, but it should be possible to replace it if the bootloader is unlocked. I think.
If someone comes out with an ARM64 Chromebook in the near future, that might be a good device to target for fully-free system efforts.
[1] https://support.lenovo.com/us/en/documents/migr-73156
If someone comes out with an ARM64 Chromebook in the near future, that might be a good device to target for fully-free system efforts.
[1] https://support.lenovo.com/us/en/documents/migr-73156
Yep, nothing past 2008 will be supported.
Which means that while this is nice and all, I got crap to be doing.
It already takes Visual Studio 3 hours to "repair" itself once a month when it stops working, and that's on a machine that would have been a supercomputer in 2008.
Which means that while this is nice and all, I got crap to be doing.
It already takes Visual Studio 3 hours to "repair" itself once a month when it stops working, and that's on a machine that would have been a supercomputer in 2008.
Sounds like a good reason to not use Visual Studio
Can I just use AMD chips to avoid this?
AMD has it's own secret firmware. it was shown off a year or two ago at Chaos, and AMD only allowed the presentation to happen if they had a PR rep onstage.
Indeed. And even ARM has TrustZone. Our governments own us. Just accept it.
TrustZone doesn't really look like Management Engine at all. Are there some documents comparing the two?
(Heavily invested in Rockchip/MediaTek chipsets. Less scared of chinese backdoors than FIVE EYES backdoors.)
(Heavily invested in Rockchip/MediaTek chipsets. Less scared of chinese backdoors than FIVE EYES backdoors.)
You're right to question this, as TrustZone isn't equivalent to Intel ME.
To explain further, here's a comment I made about this before...
https://news.ycombinator.com/item?id=11290069
To explain further, here's a comment I made about this before...
https://news.ycombinator.com/item?id=11290069
[deleted]
It does not access the network though.
For the moment, you still can, in a certain way. I've just made another lengthier comment about it elsewhere in the thread [1], before noticing yours which sadly got buried at the very bottom.
[1] - https://news.ycombinator.com/item?id=11882626
[1] - https://news.ycombinator.com/item?id=11882626
[deleted]
After the demise of PowerPC in the general computing space, what did you expect would come of Intel hegemony? BS like this. An invisible, all powerful, potentially hackable layer between the chip core and the OS sold as something to ease remote administration and enforce DRM.
Problem of security product is their designers often do shitty code with design flaw with very high privileges.
But be assured every thing is fine since for security reasons you cannot see their code.
But be assured every thing is fine since for security reasons you cannot see their code.
Does ME still access the network if you don't connect anything to the Intel network card, but use a different network card instead?
[deleted]
How does Intel ME access network? Does it use the IP address assigned to the OS or does it try to get perform DHCP?
It has to be configured to enable Intel AMT to do that, and that is if the firmware edition that has the code is installed (which I don't think is always the case). It is useful in enterprises that want remote management. It probably uses DHCP by default.
I did not find anything about ME in BIOS settings, probably the code is not present as you suggested. I have not seen any DHCP requests from the box.
My brand new Thinkpad T550 has an explicit ME config firmware I can enter. PRESS ENTER TO INTERRUPT BOOT -> F1 BIOS, F12 CUSTOM BOOT DEVICE, F9 INTEL ME SETUP
I can enter into it but its vital parts are password protected. Even though it is my computer, I cannot configure and control it. Scary. This is not the future I wanted.
I can enter into it but its vital parts are password protected. Even though it is my computer, I cannot configure and control it. Scary. This is not the future I wanted.
The default password is "admin".
Not every machine has AMT support even if the CPU and chipset support it.
Firmware level ME features are usually found on the 'enterprise' grade laptops, OS driver support for ME is another issue since that can usually be taken advantage off regardless of firmware support but it requires additional software.
Firmware level ME features are usually found on the 'enterprise' grade laptops, OS driver support for ME is another issue since that can usually be taken advantage off regardless of firmware support but it requires additional software.
I read somewhere ME (or other similar Intel technology) uses another MAC (it is off by one) not to interfere with main OS traffic. If it is really so you can setup MAC filtering on your router to block ME traffic.
But I might be wrong. For example this 2008 year document [1] says it uses same IP and MAC address as OS and filters packets by port number.
[1] http://web.archive.org/web/20080219044745/http://softwarecom...
But I might be wrong. For example this 2008 year document [1] says it uses same IP and MAC address as OS and filters packets by port number.
[1] http://web.archive.org/web/20080219044745/http://softwarecom...
If you don't trust it, it can do it any way it wants to - including spoofing traffic from the host or modulating timing of unaltered packets from the host.
I look forward to the variety of vendors who will offer RISC-V chips in the coming decade. I love Intel's approach to graphics and other drivers on Linux, they've been very helpful, and their products do often work well; however I don't think that I can bear the societal cost of something as misguided as the Management Engine. I'm perfectly happy to miss out on DRM'd consumer content on my workstation; I'm not happy to miss out on decent security principles.
How is this enabled though? Sounds like ILO/DRAC/etc., if a bit more capable. But if it's not turned on, is it that big of a deal?
If we assume Intel is malicious, they hardly need a platform like ME to do harm. And isn't this kind of stuff only available on the more expensive systems? Because they include this to sell to enterprise help desks, right?
I dislike articles that seem set to spin something. At least explain the plausible or documented reasons, then show why it's bad.
If we assume Intel is malicious, they hardly need a platform like ME to do harm. And isn't this kind of stuff only available on the more expensive systems? Because they include this to sell to enterprise help desks, right?
I dislike articles that seem set to spin something. At least explain the plausible or documented reasons, then show why it's bad.
Don't assume malice in this case, assume incompetence. And ME is on basically every intel processor made in the past 8 years
How can you know it's turned off? Remotely accessible Zero Touch Config used to stay enabled, even when it claimed "Active Management Technology: Disabled" in BIOS. PoC was shown with free Intel SCS Console and a trivially acquired certificate.
ME & AMT have become common on consumer gear, laptops, etc. and Intel chip, chipset & nics are a common combination.
The attack surface is also huge for anyone intent on compromising it.
ME & AMT have become common on consumer gear, laptops, etc. and Intel chip, chipset & nics are a common combination.
The attack surface is also huge for anyone intent on compromising it.
[deleted]
Intel should supply a ME bricking firmware !
turning it off required a special cpu with the right fuses blown, along with a special firmware version. it's baked into the cpu logic.
Anyone know if AMD suffers from a similar "feature"?
It's remarkable how a company with so many resources can make something so poorly designed.
Generally, do development boards have ME, too?
Prediction: over time, there will remain no commercially significant high-end chips without this sort of a "security subsystem." Recommending ARM, PowerPC or other architectures over x86 as the FSF suggests will not get you very far because the problem (or as chip vendors call it, the solution) is not in the ISA, it's in the chip, and every chip vendor making the sort of chip that can power a general-purpose computer will end up being this way.
Of course in practice, as long as say Linux runs on the machine, the existence of the ME or the like is almost inconsequential for the user, because you run the same software, and there's never a shortage of security vulnerabilities right there in the OS and the userspace software. In terms of the impact on the number of vulnerabilities, eliminating C and C++ would go way further than eliminating black box "security" hardware, just because the huge amount of C and C++ code, much of it written hastily and committed the moment it "runs on my machine", presents a much larger attack surface than the black box hardware + software system. But of course the FSF will never recommend ditching C and C++.
Of course in practice, as long as say Linux runs on the machine, the existence of the ME or the like is almost inconsequential for the user, because you run the same software, and there's never a shortage of security vulnerabilities right there in the OS and the userspace software. In terms of the impact on the number of vulnerabilities, eliminating C and C++ would go way further than eliminating black box "security" hardware, just because the huge amount of C and C++ code, much of it written hastily and committed the moment it "runs on my machine", presents a much larger attack surface than the black box hardware + software system. But of course the FSF will never recommend ditching C and C++.
> In terms of the impact on the number of vulnerabilities, eliminating C and C++ would go way further than eliminating black box "security" hardware, just because the huge amount of C and C++ code, much of it written hastily and committed the moment it "runs on my machine", presents a much larger attack surface than the black box hardware + software system. But of course the FSF will never recommend ditching C and C++.
This is missing the point you can and do have control over the C code which runs on your machine; the same cannot be said for ME. The comparison is entirely disingenuous.
This is missing the point you can and do have control over the C code which runs on your machine; the same cannot be said for ME. The comparison is entirely disingenuous.
Well done for turning an unrelated issue into a C++ rant!
Do you think the keylogger running on your and my machine came in by exploiting the ME or a C buffer overflow somewhere in the OS or userspace code that sister claims you "control"?
"Luckily," we don't have to choose between being afraid of firmware and afraid of C and C++. The shitty Management Engine and other firmware code will be written in C or C++ by terrible coders. The UEFI source code is over 7000 files and 100 MB of code, according to Matthew Garret:
https://www.linux.com/learn/uefi-secure-boot-big-hassle-ques... . And it can continue running once the OS has booted now (a great "feature" that was missing from the BIOS, right?)
Intel ME is a blob written by Intel however and all OEMs uses the same one. I'd bet on UEFI code being worse than the Intel ME firmware.
Isn't this kind of like arguing over which brand of hot dog has more pink slime and factory floor sweepings? They all do.
Anyway, ME is likely to be a much higher value target for hackers. A compromise there would compromise millions of PCs, whereas a UEFI hack would be specific to one vendor.
Anyway, ME is likely to be a much higher value target for hackers. A compromise there would compromise millions of PCs, whereas a UEFI hack would be specific to one vendor.
Obviously, but UEFI tends to cause more of the practical problems and attacks, including non-security ones and DoS attacks (some of which is easy to do under Windows).
Intel has a jolly video demoing how to pwn a machine remotely (framed in the positive light of taking control and fixing a boot problem by the it service desk):
http://www.intel.com/content/www/us/en/remote-support/remote...
This is for 6th generation+ cpus, but the systems in older cpus are also quite powerful. And can't really be protected beyond using a password/passphrase. I'm not sure (and probably no-one knows) if there's also a golden key/backdoor.
(I wonder if the video is actually narrated by Zach Woods (Donald 'Jared' Dunn from Silicon Valley) - or if it just sounds a bit like that).
At any rate, if watching that jolly video doesn't fill you with fear, I'd say you're not sufficiently paranoid.