The Intel ME subsystem can take over your machine, can't be audited
boingboing.net
boingboing.net
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.
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.
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.
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.
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.
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.
The win of paranoia over security and privacy.
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.
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.
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)
> 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.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...
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.
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. :(
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.
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.
If you have control over the boot process on an ARM chip, you don't have to enable Trustzone.
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!
[1] http://0pf.org/j-core.html [2] https://www.youtube.com/watch?v=lZGHbMS882w
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."
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.
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.
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.
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.
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.
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.
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.
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?
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.
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/
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!
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.
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...
(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)
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...
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.
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.
Disclaimer: I run a dedicated server host.
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.
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.
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...
https://news.ycombinator.com/item?id=10458318 (233 days)
https://news.ycombinator.com/item?id=11422531 (73 days)
https://news.ycombinator.com/item?id=8813029 (534 days)
https://news.ycombinator.com/item?id=11880935 (5 days)
Among many, many others...
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?
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.
Best usable hardware is old Intel laptops except you want something like MIPS laptop from Lemote.
[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...
Why create it in the first place? Are the enterprise uses the article mentions worth the risk?
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?
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!
The thing is: how can I configure this ME thing in order to avoid (or minimize, at least) possible attacks?
jesus wept, how do I turn it off?
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).
[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.
"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
It's common to apply this label to x86-64 too, in other words.
From https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...
"The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current (as of 2015) Intel chipsets."AMD has some rough equivalents to Intel's ME.