Hacker News new | past | comments | ask | show | jobs | submit login
The Intel ME subsystem can take over your machine, can't be audited (boingboing.net)
641 points by cylo on June 16, 2016 | hide | past | web | favorite | 271 comments



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.


ME is capable of running signed Java code

How much firmware is in the thing? Is there a whole JVM in there? An OS? That's a lot of attack surface.


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.


It is most likely running a Java Card[0] environment, which is a special embedded fork of Java, with a different (more limited) bytecode format.

[0]: https://en.wikipedia.org/wiki/Java_Card


The ME contains a fully-featured CPU and several MB worth of firmware.

That should be able to fit a full Java ME, I think.


"3 billion devices run Java" indeed.


47% of them intentionally!


Very interesting presentation. Is the video available? I had no luck with the standard searches. http://2014.ruxconbreakpoint.com/speakers/#Igor%20Skochinsky


https://www.youtube.com/watch?v=4kCICUPc9_8 seems to be basically the same talk given at Montreal rather than Melbourne


This adds a whole new dimension to 'Intel Inside'. It says exactly what anyone needs to know.

If it's for enterprise features as 'innocently' suggested that those who do not need or want this feature should be able to put it off simply without drama, debate or discussion.

Its not surprising that both AMD and ARM have it. This is an orchestrated effort signifying the win of paranoia and security over privacy in the western world.

This war is being fought on too many fronts by well resourced and paranoid security agencies with all the tools to influence and the only defense would be individuals and our sense of right and wrong. But it seems individuals have been completely disempowered and reduced to survival mode and are not in a position to stand up for the right thing or even talk about it.

If 'moral' individuals can so easily be quietened in well off economies then one wonders what happens in other economies where basic survival is a day to day fight. Who will fight the privacy war? The silence is deafening. It seems all the activism and racket from media, academics, NGOs and human rights organizations only come into play when a western political or strategic objective needs to be met.

There are many who believe that by working with and supporting security agencies they are somehow in the forefront of a nebulous fight of survival and freedom in a dark world. This 'dark world' is a self created and self serving fantasy and comedy for grown, well adjusted and well read individuals to fall for that push humanity into a negative space.

It can be taken for granted unless conclusively proved otherwise with the burden of evidence swaying the other way that any technology coming out of the USA and Europe is compromised completely and the fight for privacy here has been lost.


This is simply a barrier of resources and technology. Let's consider how software became "free". An idealist, an university and a motivated Finnish student, among many others, were able to create two complete, free operating systems and toolchains, on top of which anybody and everybody in the world could build. Now free software is a resounding reality and even increasingly adopted by large corps who were 100% closed in the past.

The germane question is, can a similar revolution happen for hardware? Can motivated individuals, or small groups of people, reasonably hope to design AND manufacture ALL the hardware for a modern computer? The answer is it's quite beyond the bounds of possibility. The tech is too complex, too closely guarded and manufacturing has HUGE upfront costs.

THAT is why hardware is currently completely dominated by a few big players, which allows them (and any other "agencies") complete control to essentially do as they wish.

We were able to make software creation egalitarian. Unless we can do the same for hardware (from ground-up), we will be ultimately controlled and never be in full control.


You're right that the barrier to open hardware is very high, but I hope that open firmware may at least help mitigate, if not solve, this problem. Buy a machine with ME-like hardware, flash the firmware with something open source and trusted and which disables ME, or returns control to the system owner.


ME operates above typical UEFI firmware. ME updates must be signed by Intel and Intel alone.


Aren't FPGAs a possible solution?


Well at least one incident seems to indicate that FPGAs can also have backdoors engineered into them just as easily: https://www.schneier.com/blog/archives/2012/05/backdoor_foun...

We need the manufacturing process to also be opened up just as much as the chip design, but the latter seems an easier goal, though in itself still difficult thanks to IP and economics.


This cruft doesn't need three letter agencies to exist. Big customers pay for it so it's done. Once it's done, it's easier to leave it there and soft-disable for people who haven't paid for it than to actually build two versions of the chip, with and without this feature.

However, speaking of spooks, I heard rumors that either Intel AMT or BIOS or some drivers (don't remember which exactly) is sold to the Chinese market with castrated crypto. Reportedly it's because the Chinese government requires imported crypto to be just strong enough to resist average guy, but not their supercomputers.


Any links re: Chinese requirements or hardware with nerfed crypto?


Sorry, I only heard it from someone who heard it from someone who heard it from someone who worked on it.

Some googling yielded this, for example:

http://www.networkworld.com/article/2331257/lan-wan/encrypti... (2004)

http://www.freshfields.com/en/global/Digital/China_rules_on_...

But this only shows that there are some regulations and licensing required, no details unfortunately.


It'd be interesting to start buying these un-un-cripple-able CPUs for use domestically, for increased security and maximum irony.


Potentially exploitable or backdoored firmware with weak crypto is no better than potentially exploitable or backdoored firmware with strong crypto, unless you are expert enough to know how to exploit it and then fix. And you probably aren't, considering that this stuff is all secret.

And, first of all, I'm not even sure if it was the ME firmware or any firmware at all. Might have been some stupid application you install on Windows.

I wouldn't buy security-critical stuff in China. You can bitch all day long about the US, but the fact is, if something like this San Bernadino phone unlock case happened in China, with Chinese phone from Chinese vendor under Chinese jurisdiction, you probably wouldn't even have heard about it.


> the win of paranoia and security over privacy

The win of paranoia over security and privacy.


Why limit your statement to "the USA and Europe"? Do you imagine the People's Republic of China is some sort of paragon of openness and transparency?


The Original Post's final sentence can be summarized as: "Unless evidence to the contrary appears, the fight for privacy in the USA and Europe has been lost." There never was such a fight in China, so neither victory nor defeat can be evidenced for it.


This is rather melodramatic. People don't care about things like Intel ME because for almost all of them, they don't ever affect their lives in any direct way at all, not because they've been beaten into submission and are in "survival mode."


Its like don't caring there's an idle remote controlled mine under your driveway. You need near perfect trust to consider yourself safe.


Joanna Rutkowska has written a nice paper on the topic, highly recommended: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

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)


I like her summary of Intel ME:

"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..."


  > GPUs without BLOBs are hard to find
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.


NICs exist, occasionally: Atheros Wifi chips work with open-source firmwares. And it shouldn't be too hard to find a GBit ethernet NIC without.

Everything else is a lost cause right now. Keyboards, mice, displays, … Everything is running proprietary firmware blobs.


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.


> Atheros Wifi chips work with open-source firmwares.

Interesting. Isn't such firmware able to initiate unlawful transmissions? How are they going to deal with this new FCC goodness?


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.


Any sources?

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.


It will likely be ignored. How do you prevent NSA from anything.


The upcoming Keyboardio model 01 has an open source firmware, you can dive in at https://github.com/keyboardio/KeyboardioFirmware


> And it shouldn't be too hard to find a GBit ethernet NIC without.

Just wonder how exactly you going to check if hardware have firmware inside it.


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.


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.


And it shouldn't be too hard to find a GBit ethernet NIC without.

I think just about every cheap, "value" (i.e. no advanced features) NIC qualifies; the Realtek ones come to mind.


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.


atheros microcode is not opensource, only the driver is. the microcode binary has a liberal license, but good luck turning that into source code.


Note that the video is also available on media.ccc.de (this is the source, youtube is just a "bad" mirror):

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


And this is why monopoly of one giant monolith is bad, in any area or case! They get to the whatever the f they want! It's not like everything is made today to track, and give access to "authorities" when they want it. But what really drives me mad is that I feel tricked! You put trust into someone and it's work, and give them money for that, but they do this, without you even knowing.

I was always making fun of sworn GNU guys, always thought they were overblowing things out of the context. But maybe they were on the track! Anyhow, I want more competitive CPU space, we need AMD to get back into game, IBMs Power9, ARM, anything. But as things are standing right now, we won't see that anytime soon.


That's why I like the initiative to revive the SuperH architecture now that the patents have run out - completely as open source. [1][2] Sure they are not fast enough to replace Intel or AMD CPU's but they could replace the smaller chips in our computers, which would be a good start.

[1] http://0pf.org/j-core.html [2] https://www.youtube.com/watch?v=lZGHbMS882w


> And this is why monopoly of one giant monolith is bad, in any area or case!

The Intel/AMD duopoly in this case is just as bad, as AMD has comparable backdoors in its hardware. The whole x86/x86_64 architecture is compromised.

> But maybe they were on the track!

https://www.reddit.com/r/stallmanwasright


I think AMD and ARM have similar features though. ARM with TrustZone for example, hiding the "secure world" from knowledge by the "normal world".


Trustzone is different, although it can be used to wall things off from the user (and their viruses) it's more of a secure hypervisor, or way of constructing a TPM-equivalent that shares chip resources.

If you have control over the boot process on an ARM chip, you don't have to enable Trustzone.


Trustzone in itself is not closed though, and FAFAIK is not a separate engine. Trustzone is more like IOMMU on steroids, and runs on the main processor (it relies on hardware support to fence off system resources).


And i think the variant found on Qualcomm SOCs were recently cracked open.


If you mean CVE-2015-6639

The Widevine QSEE TrustZone application in Android 5.x before 5.1.1 LMY49F and 6.0 before 2016-01-01 allows attackers to gain privileges via a crafted application that leverages QSEECOM access, aka internal bug 24446875.

then it's not strictly TrustZone that have been cracked, but some software running within, already patched. TrustZone itself is a hardware mechanism, basically a new level above the usual user/kernel modes.

But sure, this hack reportedly gave possibility to run arbitrary code as "trusted" and mess up any other software running on the CPU, trusted or not.


I may have gotten it confused with something else. I think it said something about Qualcomm private keys having been extracted.


Seems to be the same event.

http://www.slashgear.com/android-soc-security-keys-extracted...

I don't know what those keys were and whether they were indeed "Qualcomm private" or per-device or something else. Google quite uselessly returns only news about this hack.


Yeah I thought so, but I hoped competition would make things different, where one of leaders would go like full transparent, without these "spy" sectors, and it would give it edge over others.

And it's not about securing, it's about control! Who owns the thing I bought, that I use. It's not only they can watch, but now they can control whole computer. That's what bugs me the most. :(


See the USB Armory, which gives you the keys to control the TrustZone system (or rather, you give your public key to it so that it will only run code YOU signed).


At least you have the option to get an ARM SoC where you're the one in control, see the USB Armory.


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.


>1) Intel has such technology implemented in allmost all desktops/servers currently running

Ever wondered why Google is working on their own CPU?


Wondering - when that happens - if their firmware is open source but monitored for ad targeting should we be OK with it?


Freedom 1 of the FSF is (https://www.gnu.org/philosophy/free-sw.html):

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


opensource != free software


>> you can access those machines remotely (even over GSM)

Is this really true? All modern Intel chips come with embedded mobile phone tech to allow remote access? Sources on this?


One example source: http://www.intel.com/content/dam/doc/product-brief/mobile-co...

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."


Seems like they finally got the "Clipper" chip through... this is basically a trojan horse for spy agencies.


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.


> allowing Purism to provide this petition to our Intel Partner Account Manager

It's at least worth a shot to see what they have to say about it...


There are plenty of reasons why this is useful. See slides 7 and 8 from http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

If this functionality is a good trade-off is a different question.


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.


I wish the European Commission study this problem and if found guilty impose a fine in such a way and quantity that in no way those firms can continue exposing their clients to possible economic damage.

The previous imposed fine was of EUR 1.06 billion.

Someone with the required knowledge should submit a detailed record of this potential hazard to the European Commission emphasizing how this system could expose clients to possible threats, its anticompetitive nature, since it could allow hackers gain access to economic secrets, and many other important points.

The FSF should stand up and speak clearly. I hope and wish that the FSF execute its mission, that is to gain and gather the necessary strength to expose the nature and extend of these problems and how to fight against them.

Those that impose on us tools that allow them to control our business, steal our ideas and plans, and ruin our enterprises plaguing with chaos. Those that thrive to submit our future to their will should be fined.

I certainly hope that a new economic fine be imposed. That initiative and measure would set up a strong message and a new precedent targeted to those threating our liberty and economy. A message encoded into an economic hammer with the power to make them shape their will to respect our freedom and integrity.

To be Free and Survive we should Fight. FSF.


Unfortunately even these kind of fines are still pocket chance for such large corporation. Moreover, this is always the same issue of imposing a penalty without offering an alternative. In this case offering a hardware/software platform competing with the long established Wintel.


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.


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.


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


It could be hardware switch on motherboard.


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.


Not the signature, the payload. It's very complex. I guarantee there are bugs.


Indeed, the blob can be reverse engineered.

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.


It'd be a spectacular successor to that router-patching virus that made the rounds a while back.


just like how DVD Encryption (https://en.wikipedia.org/wiki/Content_Scramble_System) was never reverse engineered because the key was too difficult to crack ?


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.

So entirely different ballpark to CSS.


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.


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.


S boxes in DES were originally nonexistent/vulnerable to differential cryptanalysis when IBM first made Lucifer.


When has this happened? I'm curious about things that could cast the NSA in a positive light.


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


It really doesn't matter how many bits, or what cipher they used. The DRM problem is fundamentally broken:

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


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


There are phones that do have these switches.


Care to elaborate?

Asked from my N900, the only one I am aware of.


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


If they have physical access, it's over regardless of what authentication mechanisms are employed.

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.


The NSA could just produce their own chips, and put them onto your system.


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


"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.


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


Codesigning is "security-by-obscurity" now?


No, not that, the rest of it. I meant the fact that it's a binary blob which hasn't (recently) been subject to review by users.


The rest of it is covered by my second argument. They don't want you to see it due to highly proprietary stuff running there.

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?


It's better than not letting anyone see it, and also not allowing it to be changed.

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.


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


If I have physical access, I can install malware in the firmware of your WiFi card, or I can replace the whole CPU with a malicious one.

Once physical access is gained, everything is over.


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"?


IME is on the motherboard chipset, not the CPU. The i3 vs i5 is controlled by fuses set at manufacturing time on the CPU itself.


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?


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


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.


This reminds me of the anti-theft features. The laptop anti-theft arms race is ridiculous.


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.


Indeed, there was another recent HN thread on this: https://news.ycombinator.com/item?id=11880935


When people realize that it has been "truly compromised" it will be too late. The whole thing is a huge mess from a security stand-point.


Watch out for TrustZone. There are definitely flaws in it too, for example:

https://bits-please.blogspot.com/2016/06/trustzone-kernel-pr...


Seems like this has already been patched


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


all intel chipsets since 2006 have had AMT/ME, including yours


Thank you.


You use three different platforms and every have backdoors in it.


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.


The fact that the ME microcontroller can run arbitrary Java code, uploaded at runtime rather than read from ROM is pernicious. The intel private key can sign any blob, and ME would run it.

It makes me wonder, could an Java program uploaded to ME crash it or put it into an infinite loop? What would the effect be on the host OS if ME suddenly became unresponsive?

Perhaps a "Kill ME" binary could be developed as open source, and perhaps we could get Intel to sign it? If there was a strong enough request to Intel by consumers, why wouldn't they go ahead and sign it for us? No skin of their noses what we do with our consumer-grade boxes, right?


While that article is correct, it's full of FUD with the constant littering of 'secret' and 'take over' in the text.

We already know about Igor's research and the published ARC CPU reverse engineering, "Ring -3" rootkits and the DEF CON presentations. This is bad, and this needs even more reverse engineering so at some point we might add an 'open' replacement for the required ME functions and run it together with say, LibreBoot/CoreBoot.

I wonder why there haven't been any NDA ME or ARC docs leaked yet, even some of the Broadcom SOCs had those leaked and via cleanroom design proper FOSS drivers for some of the wireless parts were created... this should be possible with the Intel ME as well. Hell, even a FOSS version or at least partially reverse engineered and modified version of laptop EC firmwares have popped up on the 'net.


Yeah, the language is a bit excessive, but this is downright terrifying. Given the absurd security protections implemented in IPMI I can't imagine the successor being trustworthy enough to satisfy serious security requirements. Anyone remember the infamous cypher zero bug/feature in IPMI where you could specify an undocumented connection encryption mode which made authentication optional?


The thing about scale is that it doesn't look like ordinary individual experience. It ain't enough to run Core2/\Piledriver/\Power/\open source microcode: ME enabled computers are connected en masse to the network. The choices are air gap or head in the sand. ME was inside before Snowden.

Google, Facebook, Amazon, Ebay, Microsoft,, 百度 etc. buy Xeons by the bucketful. They're Intel's customers that matter. The retail box that comes with a fan for sale at NewEgg is just exhaust fumes. 42 or "It's the cloud": take your pick. Managing a gazillion server data center by hand just ain't practical.

Intel's customers that matter replace CPU assets on the IRS's three year depreciation schedule. It's why this [0] and why ME. Security by obscurity isn't so bad when dumping the vulnerable subsystem lowers overall costs for other reasons [performance boosts and lower power consumption].

ME is a good reason that Microsoft has been striving toward multiplatform. It no longer has such a big say in Intel's roadmap. Yes UEFI and the Windows 10 upgrade process kinda suck, but Microsoft ain't pwn'ing anyone's computer because Intel already pwn'd it. ME going sideways at scale would hurt and Microsoft would be the handy victim.

There's a strategic reason Apple is making it's own chips.

[0]: http://www.techspot.com/review/1155-affordable-dual-xeon-pc/


If you get a microscope and manage to peer into this secret hidey hole in the CPU you will see a bunch of tiny little NSA spooks, Russian and Chinese hackers scuttle away to hide in other dark hidden secret corners of the Intel CPU.


Yup. It's a good thing that we live in a universe where companies and all their employees are completely trust-worthy, and will flat-out refuse to do something illegal if asked (or incentivised) by others.

It's a good thing that all governments act within the confines of the law (both wittingly and otherwise).

It's a good thing that all software we write is correct and sound, and that no bug ever existed nor the desire to exploit such a bug should it have existed.

Paranoid people with their tinfoil hats. Shesh!


I think at this point pretty much anything on your PC is backdoorable. I can't think of a single device in my computer that doesn't respond to "magic I/O packets" which are undocumented (obviously) and prone to bugs (possibly).

Gaming mouse? Yeah send some I/O packets and you can change the DPI, USB update rate, whatever. A write-protected USB device? Uh-huh, send some magic-packets to the controllers to reset it/format it/whatever (Recently did this with one of those Dell USB Mentor Media drives that they ship the OS on). Access point? Yeah, send some magic packets and you can set the password/SSID/whatever. Hard Disk? undocumented SATA commands allows for reprogramming. This is just the 'easy' way, without going into JTAG and other diagnostic interfaces.


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.


See "The World Beyond x86" presentation for a presentation of alternatives, focusing on POWER8:

https://raptorengineering.com/TALOS/op_twbx86.php

https://static.rpteng.com/TALOS/assets/the_world_beyond_x86....


Thanks,that was a good presentation. Yap basically POWER for mid to high end and ARM for low to mid.

And it looks like AMD has its own equivalent of ME...


AMD have their counterpart, called Platform Security Processor (PSP)

see https://libreboot.org/faq/#amdpsp for more info.


If you don't need high-end single-thread performance, RISC-V will help.


Unfortunately, AMD follows all bad and destroying trust practices that were developed in Intel.


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

(as mentioned in a comparable thread five days ago: "Intel and ME, and why we should get rid of ME" (fsf.org) https://news.ycombinator.com/item?id=11880935)


Where can people go if they want a fully-libre machine and are willing to sacrifice x86?



https://libreboot.org/docs/hcl/

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)


https://www.raptorengineering.com/TALOS/prerelease.php

It's quite expensive, and prerelease, but from what I heard it fits the bill.


Outside of my price range but worth keeping an eye on. Thanks.


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.

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.


Well, the Pi blob can be replaced… almost… soon… https://news.ycombinator.com/item?id=11703842 / https://github.com/christinaa/rpi-open-firmware

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


I do actually on a Pi3, so that's an encouraging piece of info. A GPU blob is at least a step up from the ring-negative-3 management engine.


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.


rpis have even more blobs to initalize the hardware than x86/intel


Arduino


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.


Is this the company you are referencing?

https://en.wikipedia.org/wiki/Inslaw


Indeed it is.


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.


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.


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


Intel NICs are considered a premium feature on desktop boards, it is not a common sight.


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.



IPMI should always be used on a dedicated port, and on an isolated network with strict access control.

Disclaimer: I run a dedicated server host.


An isolated network isn't enough, IPMI controllers often listen on all NICs.


Not exactly, ME even without AMT is scary[1].

[1]https://libreboot.org/faq/#intelme


Yes, early versions of the ME had issues.

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.


Almost makes you want to get a Lemote Laptop like Richard Stallman.


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.


Except libreboot doesn't help. ME executes below BIOS/UEFI.


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.


> On modern systems it's will just poweroff every 30 minutes if ME firmware not present

That's highly suggestive of a hidden agenda.


You can still turn ME into "manufacturing test mode", where it will not execute things.

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


> in that mode Intel Network Cards will poweroff every 3 minutes

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?


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.


Will it also shut down add-in cards in a PCIe slot?


Nope, that’s why my 2006 Realtek card works.


I guess I should have specified Intel add-on cards, but it's easy enough to buy non-Intel.


Yes. What on earth would be the non-malicious purpose of this feature?


Wrong. On some machines, such as the X200, you can actually remove and disable the ME with coreboot/libreboot.


Interesting, I understood that wrong then. But granted, I was researching it for the x220 and it was a while ago. Thanks for the hint.


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.


There are better choices, see https://minifree.org.


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?


It's marketed as Intel vPro. Pricing is probably typical enterprise level. This page has more details: http://www.intel.com/content/www/us/en/architecture-and-tech...


Intel vPro page is way more scarer than the OP article :)

http://www.intel.com/content/www/us/en/architecture-and-tech...


Enterprise console software is likely needed to interface with the chip. And this software is probably priced like most enterprise software.


I think it is intended for enterprises to enable.


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.


AFAIK Intel AMT is documented and has been since it was introduced in 2006.


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.


Serious question: are AMD chips a viable alternative (from a security standpoint)? I hear their new Zen chips are coming soon.



AMD PSP don't have access to the network (as far as I know).


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.


Well, you can get processors from before these features existed – 2007 Intel chips or 2012 AMD chips — definitely AMD, 2012 isn't that old yet.



Thats crazy talk, in what world is it ok for my cpu to run a tcp stack on its own?


It is in the chipset not in the CPU.


Maybe I'm missing something, is this chipset on the motherboard? The article makes it seem like its coupled with the cpu.


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?


I think the AMT code is just omitted from the ME firmware.


Oh, so not very frieghtning then.


Yes.


My question is whether alternatives are secure, such as AMD or ARM? I imagine the ARM architecture to be too scrutinised and low power to get away with that sort of thing?

Personally I want to buy a laptop that is secure due to travelling to questionable places, I am wondering now whether it will include an Intel CPU in light of this.


As mentioned in comments already they are both not secure: every new AMD CPU have ARM TrustZone core in it. For ARM I can't tell since there might be SOCs without TrustZone.

Best usable hardware is old Intel laptops except you want something like MIPS laptop from Lemote.


Thanks, I'll check it out.


Possibly the Loongson 3B (https://en.wikipedia.org/wiki/Loongson#Loongson_3B - MIPS64 with hardware-assisted x86 emulation) - but someone has to take a closer look and audit it first.


Looks promising, I'll keep my eye out for machines with this processor.


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.

[1] http://www.dmtf.org/sites/default/files/standards/documents/...


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.

[1] https://software.intel.com/sites/manageability/AMT_Implement...


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?


Yes, I think it was originally intended for enterprises doing remote management.


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.


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?


People should always worry about attack surface area


OK, but that doesn't answer my first question.


Amusingly, the ARC core in the Intel ME is a descendant of the SNES SuperFX chip.


I was quite tickled to read that bit. The guy who made Starglider for the Atari ST, and Star Fox! :-) Apparently newer chips have had other architectures, at least one I think was actually SPARC.


Strange that Intel gives people more reason to go to other processors like ARM when Intel is under such pressure from competition.


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.


>AMD has all the same issues with worse performance to boot.

AMD chips aren't just slower to boot, they're slower overall!


Ferbivore probably meant "in addition", not the booting process.

http://idioms.thefreedictionary.com/to%20boot


I am pretty sure you can run VirtualBox on Linux. And you can run Linux on ARM.


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.


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".


I wasn't aware about Intel ME until recently bought a brand new Lenovo ThinkPad and saw the "Intel Management Engine" on BIOS/UEFI boot menu.

The thing is: how can I configure this ME thing in order to avoid (or minimize, at least) possible attacks?


You can't. The whole point of the thing is that it can't be disabled and will always be running to let your theoretical IT department take over your machine.


I got ME disabled in BIOS on my Lenovo S30 (manufactured around 2012 I think). Do you think this option in BIOS setup insufficient to turn it off? Is the ME still running and listening to commands coming from the network?



Has anyone on here actually used this at work?


I knew about ME, but I didn't know it had an ARC processor in it. Odd that Intel didn't opt for an in-house design, like one of their older cores backported to a newer process. (like a P54 or 386).


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.


I would use thunderbolt as it has DMA, create a CRC/F(x) cpu (external unit connected thru thunderbolt) that converts/encrypt code/data to a expected format by modified code generated by a compiler. making act the intel cpu as surrogate to it, delegating control to the CRC/F(x) cpu.

Extra points, make all the cpus work, and create extra tasks to run at the non used cpus to obscure the actual process running (yeah I know it's not energy efficient but someones has to give Intel inspiration to improve).


One thing, OK, so we have this super fantastic network enabled Java platform running autonomously from within around 3 billion devices across the globe since 2006 with the capability to read everything from the systems they are running completely unnoticed.. shouldn't this generate a FAIR amount of network traffic (and resulting suspicious log files, if not on the computers then on the routers) or am I missing something here?!


Most are not enabled/activated or connected through the NIC.


OK (sources on that being the case?), but the issue then remains that we have no way of knowing whether it is activated or could be activated, is that correct?


Sure, here's some documentation on how to enable remote management in the Intel Management Engine, if it's supported:

[1] http://www.tomshardware.com/reviews/vpro-amt-management-kvm,... [2] http://www.howtogeek.com/56538/how-to-remotely-control-your-... [3] https://communities.intel.com/thread/21261

The lack of independent audit of this chip and firmware is legitimate concern. But as you can see, if you obtain a fresh computer with access to the BIOS/UEFI, you have control over whether this functionality is enabled. If you don't have access to your BIOS/UEFI then you're correct that you won't know if it's on.


Oh my god it began with the oems installing a bunch of spyware on the default install. Many of which with vulnerabilities. Not to mention "modern" OSes not respecting users privacy. To make matters worse the hardware companies decided to follow suit and thus added unwanted and compromising features to everyday systems. Way to go! It seems I'll have to switch to stone age hardware just to have a little peace of mind. Evolution! >(


This has been in every Intel CPU since 2008


Does this apply to Macs?


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 think any MacBooks ever had built-in cellular modems…


From the article:

"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.


I think they are asking if Apple ordered chips without this ME, give the former's penchant for security. I wonder similarly.


I'm pretty sure that, for the last few generations of Intel CPUs, the ME is not optional on any (non-Atom) model.

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


Ah, fair enough. That is a good question.


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?


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


The actual ME is in the chipset itself, though it is true that full AMT functionality may require additional hardware.


Do we know if Apple uses the whole, standard Intel chipset or just the cpu + custom, Intel supplied chipset?


I think most of the time they use standard Intel chipsets, though there are exceptions.


I think it applies to everything using Intel processors.


afaik, the feature is in all newer Intel chips, so yes.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: