Nice breakdown of how ME works, but nothing new here.
Still, I'm glad I hold on to a ton of older, pre Core i-series Intel machines, AMD machines, and ARM boards. If ME is ever truly compromised at least I have a fallback or three.
Name one that doesn't. Sorry, name a modern, useful hardware platform that is 100% guaranteed not to have a backdoor or vulnerability of some sort.
It's about mitigating threats, because it's impossible to do more than that today. If you don't design and build the hardware yourself from the board and chips on up, it's not guaranteed to be safe. Even then, without being tested by the masses, you're bound to accidentally design a weakness in your system that you won't discover until you've been compromised.
So yes, I'm happy that I have older platforms with known, documented, manageable vulnerabilities to fall back on should ME's mysterious, undocumented vulnerabilities become compromised by a bad actor.
In fact, I still don't see much of a reason to upgrade quad core Yorkfield Q9xxx servers except for cheap SSD upgrades. An 8 year old desktop still compares favorably to a $700 laptop (except, of course, for electricity).
Source on that? If nobody prove it's have access to all system memory that doesn't mean PSP don't have these access. Otherwise it's will have at least MMIO-based access to the network controllers.
"On some chipsets, the firmware running on the ME implements a system called Intel's Active Management Technology (AMT). This is entirely transparent to the operating system, which means that this extra computer can do its job regardless of which operating system is installed and running on the main CPU."
Not sure. ME requires coordination/support from other electronic components to do its job. It only applies to Macs if Apple's motherboards have the necessary circuitry (I couldn't find this info so far).
As others point out, it's an Intel thing, so any Mac running an Intel chip, but I wonder if this is more of an industry thing. Has Apple put something similar in their A-series mobile chips?
More precise question is: Is Intel CPU connected with 3G laptop modem on Mac? If YES: Data can be read/written remotely from/on your Mac (even if turned OFF - as long batteries are installed). If NO: Most probably it can not be done! (Source: http://www.intel.com/content/dam/doc/product-brief/mobile-co...)
I don't know how its actually implemented, but normally to enable AMT you have to have both a compatible motherboard and processor. Intel calls it VPRO. Most desktop consumer boards do not have this feature, but quite a few of the i5 processors do.
> Most desktop consumer boards do not have this feature, but quite a few of the i5 processors do.
Considering how many firmware updates I've installed on gaming-oriented motherboards with Z-series chipsets that have included ME firmware payload, it's worth looking in to what it means for those boards to not have the feature. We know that all the transistors are physically present on both CPU and chipset. Are they truly permanently disabled with on-chip fuses, or are they just left uninitialized on boot when the microcode checks the model numbers? Are there required traces on the motherboard that are definitely being omitted/disconnected?
Why can't Intel implement proper security and open up this blob to begin with? Not opening it and not allowing to disable it, suggests it's intended for something sinister.
As stated in the article, some researchers have managed to unpack it, and it can now be dissembled.
You can't (and hpefully won't) be able to execute your own code there.
There are 2 good reasons for this:
1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.
2) I bet this firmware controlls stuff like wether your CPU is "really" a Core i3 or Core i7, how many cores are activated, etc. Basically, its reasonable to assume that the silicon is the same, but what you pay determines the actual "unlocked" performance.
> As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.
That's completely false; allowing the execution of libre software doesn't worsen security, and the security-by-obscurity model doesn't improve it.
> allowing the execution of libre software doesn't worsen security
It does if I get temporary physical access to your machine and flash something that can spy on you, or if the method of flashing it can be done via your OS and I hack that. Those are two HUGE flaws.
> 1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.
Why can't computers have physical switches that enable/disable writing the memory that this piece of software is located in?
Good question. Why don't phones have physical switches on GPS and microphones?
In this case, the RSA sig is still better, though. Imagine that anyone sitting between the Intel plant and your local computer parts supplier could flip the switch.
It's a weak argument, I admit. There should be both protections at the same time.
That is actually slightly less secure - sometimes people do have physical access to your machines.
For example, the NSA intercepted deliveries of switches and installed their malware on them. Would be easy if there is a physical switch. Not so easy if you need signed firmware (I'm sure the NSA could still do it, but it would definitely be harder).
> As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this.
No. If the thing has no persistent storage in it then just removing power from the machine would remove any such malware, and if it does have storage then it should have a "reset to factory" jumper somewhere that has the same effect.
There is no excuse for not letting the machine's owner replace any code on the machine.
> 1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.
If the code can be updated by $company, then it should also be allowed for users to update it. It's the same as the UEFI argument (though you should use CoreBoot). If it was impossible to update, then it wouldn't be a problem from a free software perspective. From a security perspective it should still be free software.
"You can't (and hpefully won't) be able to execute your own code there."
You don't have to beat the encryption scheme to executed code. You just need to jail break the signed code. If the code is complex there will be bugs and likely security holes. One sufficiently wide hole is all it takes to jail break a system.
edit: This is an example of breaking in to a jail rather than out of one.
Of course you can execute your own code, you just send a National Security Letter to Intel; or did you mean "you can't execute your own code unless you're the NSA"?
That's interesting, since the trend seems to be many of the functions motherboard did in the past (memory controller) are being moved into the cpu. Is there some reason why ME is outside the cpu? Is it really so for the newest processors?
In many cases there will be manufacturing defects resulting in errors if you try to upgrade via firmware, especially early in a products lifetime when the defect rate is high. But of course there will still be many cases where you're able to upgrade without problems.
Taking another angle: What if the computer's owner wants to use it to access her computer remotely? Are there some instructions how to do this? Is it feasible?
If not, then there seems little justification to have a relatively new feature like this turned on by default. Who is this feature really for? If it's not for all users then why is activation mandatory in CPUs after Core2?
I mean, if ME has to be active, then the computer's owner should be able to use it, right?
If that's the case and enterprises ARE using it - why isn't it more widely known about? Even if the enterprise signs an NDA - I find it surprising that it hasn;t leaked given the security implications.
It is intended for the "Intel defined enterprises" to be more precise. Ordinary Joe cannot declare him/her to be an enterprise and do so, unless he/she is willing to pay the Intel "thugs" an inordinate amount upfront.
No doubt various three-letter agencies are having a field-day with this right now.
Hopefully a robin-hood type will reverse-engineer the blob and post a permanent fix to disable this thing before a more nefarious person/group uses it to devastate the PC landscape with something even worse than bitlocker.
It's impossible to "reverse-engineer" a cryptographic signature. Properly implemented (and you can bet that Intel has had time to finalize this) it's computationally insurmountable.
Even more, an unbreakable signature can have it's private key stolen by hacking, by agencies inserting personnel into the companies, by agencies blackmailing key personnel and by agencies compelling the companies legally or ex-legally to hand them their keys.
Really, if someone has gone to the trouble of working out an exploit for Intel ME, the most ironic thing they could pull off would be to use that very exploit against Intel's own systems to steal their key, use it to patch the bugs, and release the patch to the world.
CSS is only 40 bits, which is ridiculously easy to crack. 56-bit DES keys are pretty unsafe these days, so you want at least 128 bits if you're talking private keys.
If it's using 2048-bit RSA, that's perhaps equivalent to a 256-bit private key.
Wrong. 2048-bit RSA has an effective security level of approximately 112 bits, just like 3-DES. If you want 256 bits of security, you go all the way up to 15360-bit RSA. That's why Elliptic Curve systems are so attractive: they involve operations that are more costly per-bit, but the required key sizes to meet a security level are much less. Ofcourse, Elliptic Curve Cryptography as specified by NIST has its own downsides (e.g. the 3 most common curves, prime256v1, secp384r1, and secp521r1 (128 bits, 192 bits, and 256 bits of security respectively) have constants that were chosen arbitrarily by NSA with no explanation).
Though when the NSA has done things like this in the past, we've found their choices prevented implementation weaknesses that weren't found (by anyone else) for several more years.
The DES standard's S-Boxes were changed by the NSA in the 1970s. It was long thought that this was to weaken them. However in the 1990's differential cryptanalysis was publicly discovered, and the NSA's changes to the S-boxes were found to have hardend DES agaist differential cryptanalysis.
Now here's something fascinating. According to https://en.wikipedia.org/wiki/Differential_cryptanalysis#His..., IBM discovered differential cryptanalysis in the 1970s when designing DES. They opted to keep it a secret, given its general applicability against ciphers. It is unclear whether IBM shared it with the NSA or the NSA discovered it independently, but there's strong evidence that both IBM and the NSA were aware of differential cryptanalysis well before the public discovery in the 90s.
¹ This has what looks like a good citation but requires a subscription to access the relevant paper (sigh).
Can you follow up on that? I've never heard that story and I'm really curious.
On the narrower point, though, it's been shown that Dual_EC_DRBG is broken, and that the NSA values compromised the implementation instead of strengthening it.
I still don't understand why this ME feature has been created to begin with. Assuming that breaking it is a matter of time (someone clever enough thinking about it for long enough), it seems like a serious security vulnerability, worse still because an attack is undetectable.
Why create it in the first place? Are the enterprise uses the article mentions worth the risk?
The board needs vPro/AMT for things like remote access. If the board doesn't implement those things (and you'd usually know, because you pay more for them), the ME ends up doing...well, I'm not sure what. I think mostly things like enforcing DRM? Still, the machine needs special support on the motherboard and ethernet controller to enable the features that people are complaining the most about.
If you want to avoid the ME specifically, some other not-100%-libre options you might consider are the TALOS (high performance) or the ODROID C2 (low cost)
Pi-top like laptop with your choice of pi3 or BeagleBone running Linux. The performance of a pi3 is actually decent. It's not perfect as there's a GPU BLOB in the pi3 and the BB also has some issue. It's my compromise for now, hoping the blob will be reversed/replaced eventually.
I don't think it's a big difference to be honest: The GPU firmware (start.elf) is required to boot the Pi. There is no source code available at the moment.
The GPU firmware runs in parallel to the CPU and has access to the complete memory. Video decoding is done by the GPU and happens while the CPU is completely idle. And it can (of course) crash. If you've done anything related to OMX programming on the Pi, you might have experienced that.
In theory there is nothing that would prevent the a rogue firmware from hooking into kernel structures to interface with the outside world.
You don't have to. Libreboot is available for some Thinkpads. I use an X200s. There are businesses that offer Libreboot flashing services or sell refurbished Laptops with Libreboot installed.
That's not the case. ME code is large and not bundled inside CPU. On old systems it's was possible to not provide ME firmware while keep CPU operational.
On modern systems it's will just poweroff every 30 minutes if ME firmware not present and this is why libreboot won't support any newer hardware.
And, even worse, why is there not yet a startup competing with Intel in the desktop market?
Are fabs the issues? Knowledge? Engineers? I mean, Uber got many billions in funding, with Ubers funding one could build easily a fab for 14nm process and hire all of AMD.
Yeah, between this and the power saving bugs in the last few generations of i-core processors I'm really feeling deflated about the last 2 laptops I bought. I used an Acer c710 w/coreboot+seabios and it worked so well. Good battery life, and mostly open bios. IIRC, me blobs were compiled in to coreboot but at least it worked without disabling hardware features.
The real question is what the firmware can be convinced to do remotely. Probably most of the things in here.[1] Remote management is supposed to be listening on TCP ports TCP 623 for HTTP and 664 for HTTPS.
Are you suggesting that detecting if your system is exposed to remote control is as easy as checking to see if your machine appears to have such ports open? And would the ports appear to be open if checked from the same machine?
Unclear. There are issues such as what IP address the ME is using. IP addresses are an OS level thing, and the ME is below that. Ethernet controllers don't know about IP addresses. The ME has the ability to make DHCP requests, so it can get an IP address of its own.[1]
The real question is what the ME does in addition to what it is documented to do.
I find people freaking out about this extremely strange.
AMT is Intel's equivalent of IPMI. It is a non-standard implementation of it, and does not follow any of the relevant specifications. It does not integrate into most server management platforms.
AMT costs extra. Most mobos do not have it enabled as you have to pay Intel's tax on it, even if some of the hardware to enable it is in every northbridge.
A motherboard must implement it to be available. Most of the motherboards we own don't have it enabled. You cannot "break into it" if AMT isn't available on your motherboard to begin with.
Not all ME chips can run it due to Intel's requirements.
Now, is the ME chip a threat? Possibly, not not as much as your cell phone's baseband modem is. The baseband modem can talk to outside networks, ME can't unless it is paired with a NIC it can talk to (Intel does not require mobos that have this; and generally, motherboards meant for AMT ship Intel NICs, but not always).
Without AMT, the only thing the ME does is implement management functions that allow you to actually boot and use the machine.
In the article, it says "Personally, I would like if my ME only did the most basic task it was designed for, set up the bus clocks, and then shut off," except it is kept running so you can properly sleep and wake up your machine, and also be able to change CPU frequencies at run time (IE, idle the cpu), and also provide access to the sensors on the motherboard.
In addition, the ME handles Intel Smart Connect, which is also not available on all boards (Apple uses this to implement Power Nap). It also requires licensing, the same way AMT does, and may mobo manufs simply don't want to license it.
ME does not connect to the network if it doesn't have a payload that is able to do so (AMT, Smart Connect).
The reason people don't understand what ME is for is because all of the basic tasks the ME does used to be done by lots of custom hardware, much of it not provided by Intel and different on every board, and somewhat a bit of a driver nightmare.
I don't like standing up for Intel, but anti-ME articles that continually bring up AMT as if all computers have it is FUD. Very few computers have AMT, very few computers implement this OOB access, very few computers can implement AMT even if Intel let you purchase licensing for it after purchasing the hardware.
I'm not saying that ME is not a security hazard (it can be in some cases), but it isn't some ultra awesome NSA backdoor bullshit. Your phone, however, does have the NSA backdoor.
>Now, is the ME chip a threat? Possibly, not not as much as your cell phone's baseband modem is. The baseband modem can talk to outside networks, ME can't unless it is paired with a NIC it can talk to (Intel does not require mobos that have this; and generally, motherboards meant for AMT ship Intel NICs, but not always).
The last ~dozen regular (gigabyte/asus/asrock/...) desktop PC motherboards i've seen have all used intel NICs for ethernet.
It's a lot more common than it was 2-3 years ago. ASRock, ASUS, and Gigabyte are using Intel NICs even on some boards with the low-end B150 chipset, and it's extremely common on Z170 motherboards. I can't be bothered to check the rest of the manufacturers, but it's clear that Intel NICs are popular.
Expressing a concern and "freaking out" are wholly different beasts. Most people are doing the former, but you're painting everyone with the latter brush. That's both rhetorically dishonest, and just plain uncool.
However, that website is a known source of FUD. Shame, since I used to like the FSF before it just started attacking everyone that didn't comply with their requests.
When it comes to hardware backdoors, one particular case seems to keep popping up in my mind, and that is Bill Hamilton of the infamous Inslaw/Promis octopus debacle. A few years ago when I was on Scheiers blog regular, he was claiming they had prearranged the backdoor installation at the silicon manufacturing level...
Something about that has never left my mind, and I suspect its generally correct. Heres hoping that power8 workstation Talos gets off the ground...or some risc equiv.
Very naively, I wonder what happens if you just call Intel and complain about this. Say you want a way to remove the ME completely. They won't help you, but I wonder how they will justify making it compulsory if pressed.
Now if I call them, I wouldn't reach anybody important. But surely there are a couple of people on HN who are lawyers, CEOs, with the government etc.? If you have an imposing job and a few minutes to spare, I'd like to see what Intel has to say about this.
Another lame petition won't get the same kind of results as a well connected question. The PR department lives to shield a company from such negative external noise, a well connected question can surface inside the company and be heard by people with the capability to actually do things.
Non-enterprise customers need not any of those. Hence they should be allowed to turn ME off if they wish so. That ME thing actually mean i don't have full control of my computer anymore. Anybody can access my hardware even when its turned off. Scary sh*t.
Best way to deal with issues like this, make them care. How? we need to get this message to the masses, to get enough people know about this potential issue, that it becomes an organisational issue for Intel.
(which is why I have researched non-Intel laptop alternatives..cliffnotes: GPUs without BLOBs are hard to find and there will be some severe tradeoffs which is expected)
Any devices without firmware are hard to find. Even if only some have option to upload firmware almost every device on market have closed-source firmware inside it: NICs, USB controllers, hard drives and especially modern SSD, sound cards, etc.
Good point. Usually the criterion is "can we send it a firmware blob? Can we send it an open-source firmware blob?". If you have a firmware that can't be replaced at all, it's usually handwaved away.
This is main point of many developers we can speak with in public like AMD Linux graphics team. There is a lot of people who blame them for proprietary firmware, but in same time totally okay about using tons of devices that simply not expose way to replace their firmware.
The criterion by the FSF is: If you can't replace the firmware (by somethings free), but someone else is able to change the firmware, the firmware has to be considered as malware.
But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware.
> But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware.
We have to differ here: First question is whether there is a deeper layer below and the other one whether there is additional hardware on the SoC which could also patch the (main) firmware (say: firmware update Over The Air (OTA)).
I can only give my personal private opinion on this topic:
The first question is much more easy to answer: Some instructions only work in some sufficiently privileged processor mode, so you can be pretty sure that if they occur in the firmware (and they usually will) you are in this mode. If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes (in particular for some hypothetical hypervisor). Often for realtime or microcontroller stuff older or cheaper cores are used which simply lack this capability. Since virtualization is complicated it is hardly used in firmware, in particular if there exist realtime requirements (often there will be), which are complicated to handle if you do virtualization. So you can in most cases be pretty sure that there is no hidden virtualization layer.
The much more interesting case is that there are other ICs on the SoC which could in principle patch the firmware or (much more often) access the memory (TLDR: this can be quite real). The good news is: This will usually be some specific part of the SoC and its existence can be seen or disproved if you are willing to decap/xray the chip (see for example the xray image at http://www.bunniestudios.com/blog/?p=4297). For these parts one can usually find signs in the firmware. For example if the firmware tries to communicate with another subsystem via device command or if the MMU is programmed to translate some virtual adress which doesn't seem to be backed by the chip memory (this could be some device memory) or if in the initialization code the firmware seems to try to send a patch to some device memory of another IC on the SoC. On the other hand, after decapping and xraying the chip and additionally finding no such dubious signs in the firmware, I would tend to believe that no such device exists.
TLDR: You can never be completely sure, but if such a layer exists, I'm very sure that one can find strong signs for its existence.
"If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes"
That requires trusting that the documentation is complete.
And I think such a lower layer could be hidden very well, and need not be involved in day-to-day operations. For example, in your network card it could sniff traffic, becoming active only after receiving a very specific series of packages. And the change could be as simple as ignoring a signature on over the air firmware updates.
Yes, decapping, X-raying, and years of work can always uncover such stuff, but it is the only way to be absolutely, absolutely sure. If you're China, Russia or the US and buy military hardware, I think you should be somewhat worried about this.
Funnily, the FCC requirement is incompatible with the EU laws.
The EU laws say that while a normal user shouldn’t be able to make unlawful transmissions, the manufacturer may NOT prevent the customer from installing alternative software (like openwrt) just to fulfil the first requirement.
Basically, to conform with EU law, you have to violate US law, and the other way round.
And no, it's not mutually exclusive. In principle, it should be possible to enforce regulatory constraints in hardware. But then I guess you can forget about taking this hardware to another country, unless they make this hardware as smart (read: complex) as drivers currently are.
Actually, since you mention Realtek, some of their gigabit NICs do take some firmware. I have a vague notion that it's not needed for the basic functionality of sending and receiving packets, but I might be wrong - it's been a few years since I dealt with it.
Well, I'm dumb. Of course the firmware has to be embedded in the BIOS or the chip itself, because most machines with Realtek NICs support network booting. Firmware loading in OS drivers probably only delivers updates.
So there is firmware, it can be updated by the OS, we don't know exactly what's inside. Though at least the firmware isn't designed to update the OS as in those Soviet Russia jokes.
Keyboards and mice have the distinction of being low enough resource that they can be independently implemented with cheap microcontrollers - there's currently a whole cottage industry for keyboards, spurred on by enthusiasm for discrete switches. And hopefully these microcontrollers' cheapness is enough to ward off Hanlon's razor's silicon. Furthermore, there's fewer avenues for backhaul from non-connected peripherals, especially mass backhaul.
I think in time, "Internet access" will come to be recognized as a bug, much the same way that "turing completeness" is starting to be recognized as such for programming languages. Not needed for most uses, very easy to accidentally obtain, and game-over for tractability when it shows up. The question is what a general better "restricted language" looks like that is able to accomplish all that we'd like.
"We have seen that Intel ME is potentially a very worrisome technology. We cannot know what’s really executing inside this co-processor, which is always on, and which has full access to our host system’s memory. Neither can we disable it.
If you think that this sounds like a bad joke, or a scene inspired by George Orwell’s work, dear reader, you might not be alone in your thinking..."
I think this is time for AMD or IBM's POWER8/9 to step in. If anything a little good PR vis-a-vis the "rootkit nightmare waiting to happen in your server" would be nice.
Since 2013 AMD have it's own technology called "Platform Security Processor" (PSP) which is ARM TrustZone core running signed closed-source code. It's efficiently have all the same access ME have.
Of course any processor that have PSP support not going to work without PSP firmware.
It may be, that Intel didn't plan this as an NSA/XYZ back door - but it doesn't actually matter. What matters is that we know 1) Intel has such technology implemented in allmost all desktops/servers currently running 2) you can access those machines remotely (even over GSM) and perform reads/writes.
Example misuse: somebody can put illegal stuff on your machine and then sue you...
(Intel has marketed this feature for big companies so they can format the HDD remotely over GSM in case laptop was stolen.)
They can remotely wipe my stolen machines? That's the one cool thing I've heard. How come I haven't received that email in my spam box? Poor marketing attempt if that's what they're aiming for. I'm not running a huge company but they could at least try targeting the SMB sector (I think I qualify for that). I'm against the ME vector up until it's actually useful to me.
P.S. fbi please don't hax0r me for commenting. Actually, go ahead, ya bastards.
"The freedom to study how the program works, and change it so it does your computing as you wish"
In this sense you should be able to change the firmware (since it is open source in the sense of the OSI definition) and remove the monitoring for ad targeting. If this is not possible, Google's firmware is not open source (see https://opensource.org/osd).
I guess they don't (yet) have embedded mobile phone tech. I guess they use wireless cellular modem integrated in many laptops.
EDIT: Here the relevant part from link above: "Notification via an encrypted SMS text message over a 3G network. For this option, the laptop does not need to be connected to the Internet. This feature works even if the OS in not running or has been reinstalled, thanks to a hardware-to-hardware link between the 3G card and the Intel AT system."
Igor Skochinsky (of IDA Hex-Rays fame, among others) has been studying Intel ME for quite some time. He gave a nice talk at Breakpoint summarizing what he'd discovered (slides here [pdf]: https://github.com/skochinsky/papers/blob/master/2014-10%20%...).
Among other things, he finds that ME is capable of running signed Java code which is pushed to the device. Due to the complexity and size of the Java code, it's quite likely to have bugs.
ME is a bit scary partly because it's a totally closed-source and proprietary component of your computer with full and essentially unfettered access to everything - RAM, peripherals, and network I/O. Any bug in a publicly-accessible component would have the potential to do serious damage. For example, a bug in the network stack might make it possible for attackers to remotely own your box.
There is an embedded RTOS (ThreadX) and an embedded JVM. Curiously the embedded JVM uses JEFF bytecode, a somewhat obscure bytecode format for embedded JVMs. Java Card does _not_ use JEFF¹, meaning it's either an Intel-proprietary JVM or, more likely, they licensed it from an unknown party.
And yes, there's a hell of a lot of attack surface. Someone's gonna hack ME one day and have access to an awful lot of computers.
¹ I think. I'm far from an embedded Java expert, but from what I can tell Java Card uses a reduced form of regular Java bytecode and not a totally different format like JEFF. Please correct me if I'm wrong.
I'm very surprised that no-one on HN has talked about their experiences of using AMT for enterprise IT management. Aside from the security problems, I've personally never encountered or seen it's use, which makes the ME's inclusion (on all chips, for about 6 years) seem like an odd decision from Intel.
> I've personally never encountered or seen it's use, which makes the ME's inclusion (on all chips, for about 6 years) seem like an odd decision from Intel.
I consider it as quite plausible that the reason why Intel included ME into all chips is that it is much cheaper to add those unnecessary gates to any chip than to create two different versions of it. The much more interesting question is why ME cannot be disabled. It is clear (see http://www.intel.com/content/dam/doc/product-brief/mobile-co...) why Intel has a reason why ME should not be possible to disable on some chips. I can imagine that Intel fears that if it can be disabled on some chips, hackers will find a backdoor to also disable it on those chips where it shouldn't be possible.
> it is clear why Intel has a reason why ME should not be possible to disable on some chips.
Only "under some conditions" should not be possible, that is, once you as a user turn on the anti-theft protection. Theoretically, turn-on-once, afterwards-no-turn-off technology can be implemented.
My previous employer used it, and it was pretty useful. When we got a new PC, we'd enroll our local keys by booting with a USB drive with the keyfile in the root of the filesystem. The firmware would offer to enroll the keys, after which (remote) sysadmins could remotely administer the machine through AMT -- basically a remote KVM.
The firmware has an on-screen indication that's happening, so it couldn't be used for spying. Plus for most day-to-day purposes, we could use AD to administer the machines (which probably could be used for spying, if that were necessary). But when things broke enough that AD stopped working (or when first setting up a box), much of the time AMT meant that we didn't need a physical presence to fix them again.
Its nice, I've seen demos of it. Its probably not in use a lot because there are so many better management suites out there. System Center on the expensive end, which is native MS, and a slew of other things on the lower end.
We just replaced our System Center setup and now use a mix of Spiceworks and PQDeploy, but we certainly could have looked at using AMT. Its such a buyers market and other apps have more features, it just didn't seem worth looking into. Intel's AMT/ME stuff seems more barebones than competitors. I can see why other shops are shying away from it.
FWIW, System Center was really, really nice and I wish we could have kept it, but MS discontinued the small office version of it and moving to the big boy version was just cost prohibitive. Unless you have over 250 machines to babysit, SC isn't worth it. SC eats a lot of competitors lunches. I suspect this is why big shops don't bother with AMT.
Also, AMT being unstoppable is a feature not a bug. You don't want end users being able to disable it or make changes if you manage an IT environment, even if they are local admins.
Such decisions are not made in the face of pressure. I think, they are made years ago and now they are (still) executed.
In the corporation centers, nobody thinks of critical users that look very carefully on things. They mostly think about the average user, that just wants more "power".
Who does this give reason to move to ARM? End-users generally don't have a choice (good luck running AutoCAD on ARM) and OEMs either don't seem to care or list ME as one of the selling points of their systems.
You could make the case that this might convince people to use AMD CPUs, but from what I hear AMD has all the same issues with worse performance to boot.
But VirtualBox doesn't emulate different instructions sets, so you would have to run ARM windows inside of it and an ARM build of AutoCAD (which I don't believe exists).
Also I'm not sure that VirtualBox supports ARM at all.
Can someone tell me if people have actually spotted the Intel ME doing unauthorized communication?
I imagine it should be easy to spot in any network firewall log (note I said network, not OS), and in reality, if it's never been observed to communicate with the outside world without explicitly being told to then do people really need to worry?
281 comments
[ 2.7 ms ] story [ 250 ms ] threadStill, I'm glad I hold on to a ton of older, pre Core i-series Intel machines, AMD machines, and ARM boards. If ME is ever truly compromised at least I have a fallback or three.
https://bits-please.blogspot.com/2016/06/trustzone-kernel-pr...
It's about mitigating threats, because it's impossible to do more than that today. If you don't design and build the hardware yourself from the board and chips on up, it's not guaranteed to be safe. Even then, without being tested by the masses, you're bound to accidentally design a weakness in your system that you won't discover until you've been compromised.
So yes, I'm happy that I have older platforms with known, documented, manageable vulnerabilities to fall back on should ME's mysterious, undocumented vulnerabilities become compromised by a bad actor.
"On some chipsets, the firmware running on the ME implements a system called Intel's Active Management Technology (AMT). This is entirely transparent to the operating system, which means that this extra computer can do its job regardless of which operating system is installed and running on the main CPU."
So it sounds like yes, this would effect any OS.
https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem... https://puri.sm/posts/petition-for-intel-to-release-an-me-le...
> All recent Intel systems (made in the last 8 or 9 years) has this. The ME will never be freed
Considering how many firmware updates I've installed on gaming-oriented motherboards with Z-series chipsets that have included ME firmware payload, it's worth looking in to what it means for those boards to not have the feature. We know that all the transistors are physically present on both CPU and chipset. Are they truly permanently disabled with on-chip fuses, or are they just left uninitialized on boot when the microcode checks the model numbers? Are there required traces on the motherboard that are definitely being omitted/disconnected?
AMD has some rough equivalents to Intel's ME.
You can't (and hpefully won't) be able to execute your own code there.
There are 2 good reasons for this:
1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker.
2) I bet this firmware controlls stuff like wether your CPU is "really" a Core i3 or Core i7, how many cores are activated, etc. Basically, its reasonable to assume that the silicon is the same, but what you pay determines the actual "unlocked" performance.
That's completely false; allowing the execution of libre software doesn't worsen security, and the security-by-obscurity model doesn't improve it.
And if you agree about code signing, do you really believe that letting everyone see it, but then not allow anyone else to change it, is a good idea?
At least in the case where the code can be inspected, it can be checked for vulnerabilities, backdoors, etc.
That is better than nothing, especially if the vendor can be asked for a fix.
It does if I get temporary physical access to your machine and flash something that can spy on you, or if the method of flashing it can be done via your OS and I hack that. Those are two HUGE flaws.
Once physical access is gained, everything is over.
Why can't computers have physical switches that enable/disable writing the memory that this piece of software is located in?
In this case, the RSA sig is still better, though. Imagine that anyone sitting between the Intel plant and your local computer parts supplier could flip the switch.
It's a weak argument, I admit. There should be both protections at the same time.
Asked from my N900, the only one I am aware of.
For example, the NSA intercepted deliveries of switches and installed their malware on them. Would be easy if there is a physical switch. Not so easy if you need signed firmware (I'm sure the NSA could still do it, but it would definitely be harder).
I'd argue that not being able to modify software subjects you to a higher risk because you wont be able to fix security vulnerabilities yourself.
Software and hardware outlive the companies that produce them.
No. If the thing has no persistent storage in it then just removing power from the machine would remove any such malware, and if it does have storage then it should have a "reset to factory" jumper somewhere that has the same effect.
There is no excuse for not letting the machine's owner replace any code on the machine.
If the code can be updated by $company, then it should also be allowed for users to update it. It's the same as the UEFI argument (though you should use CoreBoot). If it was impossible to update, then it wouldn't be a problem from a free software perspective. From a security perspective it should still be free software.
You don't have to beat the encryption scheme to executed code. You just need to jail break the signed code. If the code is complex there will be bugs and likely security holes. One sufficiently wide hole is all it takes to jail break a system.
edit: This is an example of breaking in to a jail rather than out of one.
If not, then there seems little justification to have a relatively new feature like this turned on by default. Who is this feature really for? If it's not for all users then why is activation mandatory in CPUs after Core2?
I mean, if ME has to be active, then the computer's owner should be able to use it, right?
http://www.intel.com/content/www/us/en/architecture-and-tech...
Hopefully a robin-hood type will reverse-engineer the blob and post a permanent fix to disable this thing before a more nefarious person/group uses it to devastate the PC landscape with something even worse than bitlocker.
Even more, an unbreakable signature can have it's private key stolen by hacking, by agencies inserting personnel into the companies, by agencies blackmailing key personnel and by agencies compelling the companies legally or ex-legally to hand them their keys.
If it's using 2048-bit RSA, that's perhaps equivalent to a 256-bit private key.
So entirely different ballpark to CSS.
¹ This has what looks like a good citation but requires a subscription to access the relevant paper (sigh).
On the narrower point, though, it's been shown that Dual_EC_DRBG is broken, and that the NSA values compromised the implementation instead of strengthening it.
1. Hand the ciphertext to the opponent.
2. Hand the decryption algorithm to the opponent, embedded in a software or hardware device.
3. Hand the key to the opponent, possibly embedded in the hardware.
4. Ask your opponent to decrypt the ciphertext, view the plaintext, and then kindly not copy the plaintext in any other way.
Why create it in the first place? Are the enterprise uses the article mentions worth the risk?
If you want to avoid the ME specifically, some other not-100%-libre options you might consider are the TALOS (high performance) or the ODROID C2 (low cost)
It's quite expensive, and prerelease, but from what I heard it fits the bill.
Or anything that runs libreboot: https://libreboot.org/docs/hcl/
If OpenBSD runs on it that's also a good sign usually as they won't touch anything with BLOBs.
The GPU firmware runs in parallel to the CPU and has access to the complete memory. Video decoding is done by the GPU and happens while the CPU is completely idle. And it can (of course) crash. If you've done anything related to OMX programming on the Pi, you might have experienced that.
In theory there is nothing that would prevent the a rogue firmware from hooking into kernel structures to interface with the outside world.
Not a ready drop-in replacement yet, but running ARM code with access to the SD card and the UART console is possible!
edit: By the way! The Pi loads all the firmware from the SD card — no reflashable memory on the board AFAIK – which would make it excellent from the "State considered harmful" perspective http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
http://riscv.org/ http://www.lowrisc.org/
http://0pf.org/ http://j-core.org/
On modern systems it's will just poweroff every 30 minutes if ME firmware not present and this is why libreboot won't support any newer hardware.
That's highly suggestive of a hidden agenda.
But in that mode Intel Network Cards will poweroff every 3 minutes.
I wondered why my I219-V didn’t work, until I found it worked with ME in normal mode.
Now I’m back on a 2006 100M Realtek NIC
This is ridiculous. This is not a rootkit waiting to happen, it's already an operational rootkit!
What is this company trying to achieve? Is this a military asset designed to attack foreign countries? Is the Cold War not over?
Are fabs the issues? Knowledge? Engineers? I mean, Uber got many billions in funding, with Ubers funding one could build easily a fab for 14nm process and hire all of AMD.
[1] http://www.dmtf.org/sites/default/files/standards/documents/...
The real question is what the ME does in addition to what it is documented to do.
[1] https://software.intel.com/sites/manageability/AMT_Implement...
AMT is Intel's equivalent of IPMI. It is a non-standard implementation of it, and does not follow any of the relevant specifications. It does not integrate into most server management platforms.
AMT costs extra. Most mobos do not have it enabled as you have to pay Intel's tax on it, even if some of the hardware to enable it is in every northbridge.
A motherboard must implement it to be available. Most of the motherboards we own don't have it enabled. You cannot "break into it" if AMT isn't available on your motherboard to begin with.
Not all ME chips can run it due to Intel's requirements.
Now, is the ME chip a threat? Possibly, not not as much as your cell phone's baseband modem is. The baseband modem can talk to outside networks, ME can't unless it is paired with a NIC it can talk to (Intel does not require mobos that have this; and generally, motherboards meant for AMT ship Intel NICs, but not always).
Without AMT, the only thing the ME does is implement management functions that allow you to actually boot and use the machine.
In the article, it says "Personally, I would like if my ME only did the most basic task it was designed for, set up the bus clocks, and then shut off," except it is kept running so you can properly sleep and wake up your machine, and also be able to change CPU frequencies at run time (IE, idle the cpu), and also provide access to the sensors on the motherboard.
In addition, the ME handles Intel Smart Connect, which is also not available on all boards (Apple uses this to implement Power Nap). It also requires licensing, the same way AMT does, and may mobo manufs simply don't want to license it.
ME does not connect to the network if it doesn't have a payload that is able to do so (AMT, Smart Connect).
The reason people don't understand what ME is for is because all of the basic tasks the ME does used to be done by lots of custom hardware, much of it not provided by Intel and different on every board, and somewhat a bit of a driver nightmare.
I don't like standing up for Intel, but anti-ME articles that continually bring up AMT as if all computers have it is FUD. Very few computers have AMT, very few computers implement this OOB access, very few computers can implement AMT even if Intel let you purchase licensing for it after purchasing the hardware.
I'm not saying that ME is not a security hazard (it can be in some cases), but it isn't some ultra awesome NSA backdoor bullshit. Your phone, however, does have the NSA backdoor.
The last ~dozen regular (gigabyte/asus/asrock/...) desktop PC motherboards i've seen have all used intel NICs for ethernet.
https://www.youtube.com/watch?v=GZeUntdObCA https://lwn.net/Articles/630778/ http://fish2.com/ipmi/
Disclaimer: I run a dedicated server host.
[1]https://libreboot.org/faq/#intelme
However, that website is a known source of FUD. Shame, since I used to like the FSF before it just started attacking everyone that didn't comply with their requests.
Something about that has never left my mind, and I suspect its generally correct. Heres hoping that power8 workstation Talos gets off the ground...or some risc equiv.
https://en.wikipedia.org/wiki/Inslaw
Now if I call them, I wouldn't reach anybody important. But surely there are a couple of people on HN who are lawyers, CEOs, with the government etc.? If you have an imposing job and a few minutes to spare, I'd like to see what Intel has to say about this.
It's at least worth a shot to see what they have to say about it...
If this functionality is a good trade-off is a different question.
Edit: There's also a talk from 32c3 for those more inclined to watch a video. I am pretty worried ever since I watched that: https://www.youtube.com/watch?v=rcwngbUrZNg
(which is why I have researched non-Intel laptop alternatives..cliffnotes: GPUs without BLOBs are hard to find and there will be some severe tradeoffs which is expected)
Everything else is a lost cause right now. Keyboards, mice, displays, … Everything is running proprietary firmware blobs.
Just wonder how exactly you going to check if hardware have firmware inside it.
We have to differ here: First question is whether there is a deeper layer below and the other one whether there is additional hardware on the SoC which could also patch the (main) firmware (say: firmware update Over The Air (OTA)).
I can only give my personal private opinion on this topic:
The first question is much more easy to answer: Some instructions only work in some sufficiently privileged processor mode, so you can be pretty sure that if they occur in the firmware (and they usually will) you are in this mode. If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes (in particular for some hypothetical hypervisor). Often for realtime or microcontroller stuff older or cheaper cores are used which simply lack this capability. Since virtualization is complicated it is hardly used in firmware, in particular if there exist realtime requirements (often there will be), which are complicated to handle if you do virtualization. So you can in most cases be pretty sure that there is no hidden virtualization layer.
The much more interesting case is that there are other ICs on the SoC which could in principle patch the firmware or (much more often) access the memory (TLDR: this can be quite real). The good news is: This will usually be some specific part of the SoC and its existence can be seen or disproved if you are willing to decap/xray the chip (see for example the xray image at http://www.bunniestudios.com/blog/?p=4297). For these parts one can usually find signs in the firmware. For example if the firmware tries to communicate with another subsystem via device command or if the MMU is programmed to translate some virtual adress which doesn't seem to be backed by the chip memory (this could be some device memory) or if in the initialization code the firmware seems to try to send a patch to some device memory of another IC on the SoC. On the other hand, after decapping and xraying the chip and additionally finding no such dubious signs in the firmware, I would tend to believe that no such device exists.
TLDR: You can never be completely sure, but if such a layer exists, I'm very sure that one can find strong signs for its existence.
That requires trusting that the documentation is complete.
And I think such a lower layer could be hidden very well, and need not be involved in day-to-day operations. For example, in your network card it could sniff traffic, becoming active only after receiving a very specific series of packages. And the change could be as simple as ignoring a signature on over the air firmware updates.
Yes, decapping, X-raying, and years of work can always uncover such stuff, but it is the only way to be absolutely, absolutely sure. If you're China, Russia or the US and buy military hardware, I think you should be somewhat worried about this.
Interesting. Isn't such firmware able to initiate unlawful transmissions? How are they going to deal with this new FCC goodness?
The EU laws say that while a normal user shouldn’t be able to make unlawful transmissions, the manufacturer may NOT prevent the customer from installing alternative software (like openwrt) just to fulfil the first requirement.
Basically, to conform with EU law, you have to violate US law, and the other way round.
And no, it's not mutually exclusive. In principle, it should be possible to enforce regulatory constraints in hardware. But then I guess you can forget about taking this hardware to another country, unless they make this hardware as smart (read: complex) as drivers currently are.
I think just about every cheap, "value" (i.e. no advanced features) NIC qualifies; the Realtek ones come to mind.
So there is firmware, it can be updated by the OS, we don't know exactly what's inside. Though at least the firmware isn't designed to update the OS as in those Soviet Russia jokes.
I think in time, "Internet access" will come to be recognized as a bug, much the same way that "turing completeness" is starting to be recognized as such for programming languages. Not needed for most uses, very easy to accidentally obtain, and game-over for tractability when it shows up. The question is what a general better "restricted language" looks like that is able to accomplish all that we'd like.
"We have seen that Intel ME is potentially a very worrisome technology. We cannot know what’s really executing inside this co-processor, which is always on, and which has full access to our host system’s memory. Neither can we disable it.
If you think that this sounds like a bad joke, or a scene inspired by George Orwell’s work, dear reader, you might not be alone in your thinking..."
https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...
This is her corresponding blog post:
http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
see https://libreboot.org/faq/#amdpsp for more info.
Of course any processor that have PSP support not going to work without PSP firmware.
https://raptorengineering.com/TALOS/op_twbx86.php
https://static.rpteng.com/TALOS/assets/the_world_beyond_x86....
And it looks like AMD has its own equivalent of ME...
Example misuse: somebody can put illegal stuff on your machine and then sue you...
(Intel has marketed this feature for big companies so they can format the HDD remotely over GSM in case laptop was stolen.)
P.S. fbi please don't hax0r me for commenting. Actually, go ahead, ya bastards.
Ever wondered why Google is working on their own CPU?
"The freedom to study how the program works, and change it so it does your computing as you wish"
In this sense you should be able to change the firmware (since it is open source in the sense of the OSI definition) and remove the monitoring for ad targeting. If this is not possible, Google's firmware is not open source (see https://opensource.org/osd).
Is this really true? All modern Intel chips come with embedded mobile phone tech to allow remote access? Sources on this?
I guess they don't (yet) have embedded mobile phone tech. I guess they use wireless cellular modem integrated in many laptops.
EDIT: Here the relevant part from link above: "Notification via an encrypted SMS text message over a 3G network. For this option, the laptop does not need to be connected to the Internet. This feature works even if the OS in not running or has been reinstalled, thanks to a hardware-to-hardware link between the 3G card and the Intel AT system."
Among other things, he finds that ME is capable of running signed Java code which is pushed to the device. Due to the complexity and size of the Java code, it's quite likely to have bugs.
ME is a bit scary partly because it's a totally closed-source and proprietary component of your computer with full and essentially unfettered access to everything - RAM, peripherals, and network I/O. Any bug in a publicly-accessible component would have the potential to do serious damage. For example, a bug in the network stack might make it possible for attackers to remotely own your box.
How much firmware is in the thing? Is there a whole JVM in there? An OS? That's a lot of attack surface.
That should be able to fit a full Java ME, I think.
[0]: https://en.wikipedia.org/wiki/Java_Card
And yes, there's a hell of a lot of attack surface. Someone's gonna hack ME one day and have access to an awful lot of computers.
¹ I think. I'm far from an embedded Java expert, but from what I can tell Java Card uses a reduced form of regular Java bytecode and not a totally different format like JEFF. Please correct me if I'm wrong.
I consider it as quite plausible that the reason why Intel included ME into all chips is that it is much cheaper to add those unnecessary gates to any chip than to create two different versions of it. The much more interesting question is why ME cannot be disabled. It is clear (see http://www.intel.com/content/dam/doc/product-brief/mobile-co...) why Intel has a reason why ME should not be possible to disable on some chips. I can imagine that Intel fears that if it can be disabled on some chips, hackers will find a backdoor to also disable it on those chips where it shouldn't be possible.
Only "under some conditions" should not be possible, that is, once you as a user turn on the anti-theft protection. Theoretically, turn-on-once, afterwards-no-turn-off technology can be implemented.
The firmware has an on-screen indication that's happening, so it couldn't be used for spying. Plus for most day-to-day purposes, we could use AD to administer the machines (which probably could be used for spying, if that were necessary). But when things broke enough that AD stopped working (or when first setting up a box), much of the time AMT meant that we didn't need a physical presence to fix them again.
We just replaced our System Center setup and now use a mix of Spiceworks and PQDeploy, but we certainly could have looked at using AMT. Its such a buyers market and other apps have more features, it just didn't seem worth looking into. Intel's AMT/ME stuff seems more barebones than competitors. I can see why other shops are shying away from it.
FWIW, System Center was really, really nice and I wish we could have kept it, but MS discontinued the small office version of it and moving to the big boy version was just cost prohibitive. Unless you have over 250 machines to babysit, SC isn't worth it. SC eats a lot of competitors lunches. I suspect this is why big shops don't bother with AMT.
Also, AMT being unstoppable is a feature not a bug. You don't want end users being able to disable it or make changes if you manage an IT environment, even if they are local admins.
In the corporation centers, nobody thinks of critical users that look very carefully on things. They mostly think about the average user, that just wants more "power".
You could make the case that this might convince people to use AMD CPUs, but from what I hear AMD has all the same issues with worse performance to boot.
Also I'm not sure that VirtualBox supports ARM at all.
AMD chips aren't just slower to boot, they're slower overall!
http://idioms.thefreedictionary.com/to%20boot
I imagine it should be easy to spot in any network firewall log (note I said network, not OS), and in reality, if it's never been observed to communicate with the outside world without explicitly being told to then do people really need to worry?