Intel finds critical holes in secret Management Engine hidden in tons of desktop, server chipsets Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts. The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, …
....."Fuel demands for Intel to ship components free of its Management Engine – or provide a way to fully disable it – so people can use their PCs without worrying about security bugs in secluded computers.".....
How will 'Trusted Computing' Model 2.0 vested interests take this news???
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
==========
....."The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility," (EFF)...
Who knows. Perhaps NSA saw what Intel was up to and simply decided to let them get on with it, knowing that they'd fsck it up badly to NSA's advantage.
Why bother coercing / cajoling Intel into slipping in a hidden backdoor when you know they'll build in aircraft hangar sized doors through sheer incompetence... So long as Intel stick to this idea of an ME, there's code there that will likely have flaws.
Raptor Engineering are up to something interesting with OpenPower. Basically with the Power9 CPU from IBM being "open source", they're in a movement to do a completely open source computer (all the way down to the silicon design, board schematics, firmware, and of course the OS + software stack on top). It's all there for one's inspection.
No magic closed source firmware / ME there.
Basically with the Power9 CPU from IBM being "open source", they're in a movement to do a completely open source computer (all the way down to the silicon design, board schematics, firmware, and of course the OS + software stack on top). It's all there for one's inspection.
SPARC is also open source.
Sparc may be Open Source, but Sun/Oracle's SC (System Controller - essentially the same as Intel's ME) is not. However, it is not "on-chip", but a separate plug-in so you can unplug the whole board if you want peace of mind. I have not tried it, and can't promise your machine will still boot without an SC. <p>
Older Sun kit did lights out by serial line - which you connected to your own terminal server - completely avoiding the need for a tin hat. <p>
Personally, I think the relevant APIs should be documented and Arduinos from third parties used as SC/ME devices with Open Source code.<p>
Mine is the one with the tin-foil hat in the pocket.
Sparc may be Open Source, but Sun/Oracle's SC (System Controller - essentially the same as Intel's ME) is not.
Not really relevant, though. An SC is a system controller, you can use a SPARC processor without any need for one, that will depend on your system design. Just as with Power, you can design a SPARC system to make no use of any additional controller if you don't need one. Intel's ME is a core that is integrated into the processor, you have it whether you want it or not, and since the processor is not open source you can't even fab one that doesn't have it, which is the problem.
"...SPARC is also open source..."
Yes, but SPARC is also now owned by Oracle, and if you've watched what they did with the open source Java library, you'd understand that making changes and including other functionality is at risk of being later litigated. Oracle knows how to kill any standard. Even as "open source" as SPARC or POWER is, I personally think the way forward will be based on RISC-V, and it'll probably even kill off ARM eventually. The whole RISC-V ISA was written from researchers and academia and is all in the public domain. Essentially anyone can take the ISA and push it into their own ASIC or FPGA, and they are wrapping their ISA commits into Linux kernel 4.15. There are already 3rd party vendors like SiFive and lowRISC who are packaging up 4+1 core configurations to work on modern fabs for turnkey stuff running between 16-64bit instructions, with a pre-planned path to 128 bit instructions.
You... may want to take another look at that partnership - Fujitsu is not totally independently producing SPARC processors, or modifying the ISA they way they feel like it. It's more like Fujitsu is a glove and Oracle is the hand inside it - and the tool the gloved hand picks up is more or less Oracle-only software... Kind of makes my point actually - like the MySQL fiasco, and the ongoing Java saga. Because Oracle own the copyright to SPARC, MySQL, and Java - they can and in actuality have the right to do whatever they want with the license at any time, which gives them an enormous amount of power over the users of those items. Just look at how hard Oracle has been going after Google for Java, it's a valid risk having that hanging over one's head.
Why bother coercing / cajoling Intel into slipping in a hidden backdoor when you know they'll build in aircraft hangar sized doors through sheer incompetence.
You might, as an organisation tasked with securing the nation, consider that leaving your own economy and infrastructure vastly more vulnerable to a foreign attack wasn't a good price to pay to be able to read the emails of a few minority protest groups
"...Who knows. Perhaps NSA saw what Intel was up to and simply decided to let them get on with it, knowing that they'd fsck it up badly to NSA's advantage.
Why bother coercing / cajoling Intel into slipping in a hidden backdoor when you know they'll build in aircraft hangar sized doors through sheer incompetence... So long as Intel stick to this idea of an ME, there's code there that will likely have flaws..."
I think this is exactly it, and that's why the NSA asked for a "High Assurance" firmware option be made available that is part of all secure system orders - which disables the whole suite of Intel ME functionality. The same guys who found these bugs have been following the breadcrumbs left by the NSA for this research.
This build in bug has been known about for some time, plenty long enough for every state security agency in the world to have found ways to make use of it. Even it Intel provide a method of disabling the Management Engine, who's to say it can't be reversed or will just continue to work ignoring whatever updates provided by Intel?
No, Apple computers have the same problem. Every modern x86 CPU / platform has an equivalent to the ME, ostensibly to allow remote administration (in one of the most insecure ways possible), but when you dig into it a bit more and look at things like PAVP the real reason appears to be implementing unbreakable DRM on all consumer platforms. The kind of DRM that means you are only a less-privileged user of "your" computer, sadly....
Apple computers don't have AMT, as reported by this esteemed organ in May this year.
The hidden web server test (http://localhost:16992 or http://other.lan.ip:16992) fails on my Mac, whereas if you were to try that on e.g. a Dell Wintel aimed at business it'll probably work.
Not that the web server is the only way to exploit it.
So when are companies going to fill the niche market of backdoor-less computing? Low end computers without black-box Management Engine / Secure Boot /... might start to look attractive for more security-sensitive applications. It looks like the hardware can be easily custom manufactured (e.g., simple ARM development platforms such as the new Arduinos, or bigger ones like the Samsung Artik). Something like MINIX might be enough to create a functional (and transparent) platform. Create an audit trail to certify the software and sell it under a Swiss brand name.
"...If that's above your budget you could try a Beowulf cluster of Raspberry Pis..."
All ARM have Trustzone (even RPi). It's not the system space level that is being attacked, it's the lower debug/management level that's being attacked. If you look at the graphic at: https://www.arm.com/products/security-on-arm/trustzone you'll see there is a secure software stack, a non-secure software stack - and debug going outside of both stacks. Though Trustzone hasn't been broken YET (that I'm aware of), I fathom once people actually start looking very critically at it (like researchers did this year with AMT and ME), it will not be long before critical and embarrassing failures of security are discovered there too. This model of having a "secret" system doing work below the known system, is pure and simply security by obscurity. It's much better to just document that dang thing, get the problems found and fixed within a generation or two of silicon, rather than put a decade's worth of silicon in the field and find out the plan was a bad one. Unless Intel's "fix" is to blow a physical fuse on the die as part of a software update to disable the entire block of hardware, I cannot in good faith trust their fix is permanent. Since the current security failure allows analysis of the whole ME system, that means even the fix can be observed already, analyzed and picked apart, then scrutinized for more weaknesses.
Securing a system is hard enough without the ME engine in there, regardless that Intel marketing and public relations doesn't want the ME system called a back door. When you show the world your goatse, all you want people to do is stop looking at it - but trust me, it's hard to un-see from back there. ;-)
Not if you want all the bells and whistles that are built into modern CPUs.
Do you want various levels of cache on-chip? How about microcode to pipeline instructions to available cores/processors? I think there are a lot of added enhancements to support extended and virtualization of memory, peripherals, interrupt handling.
My hardware days are many years in the past but the pattern was to move more and more peripheral processing closer to the CPU - along with the need to be able to update the underlying processor chip instruction sets.
I think the end goal would be for every user to see where every bit comes and goes in all cases. Probably several orders of magnitude than all of the currently configured processors could compute - if you believed them.
Unable to be disabled....check!
Cryptographically locked to prevent machine owners from altering it...check!
Super secretive about true capabilities.....check!
Used for DRM purposes (thus making vendor true owner)....check!
Mandatory in all of the vendor's CPU lineup....check!
The ME and PSP are really two sides of the same coin, unfortunately.
Yeah, the funny thing is Intel isn't too loud on talking about it or how it works when it comes to their system, but AMD is pretty open about it and goes into quite a deal of detail discussing it, even using it in marketing as a promotional point for EPYC. Makes me wonder why htey are so much more open about their chip, what it is and what it can do, than Intel.
Eh, AMD isn't all that great here either. Whenever you get close to figuring out how to interact with the PSP at anything other than a consumer level you run into a "burn after reading" NDA requirement, which makes it not a whole lot different than Intel. Remember, Intel's also been fairly public about AMT itself, and I'd say that AMD's marketing is just that -- marketing, focusing on how the PSP can be used to "secure" machines instead of what the PSP really is (a backdoor waiting to be activated).
At the end of the day it makes no difference that you know how a backdoor works if you can't deactivate or disable it....
Because, fundamentally, it's the same basic design. A vendor-provided, vendor-locked binary running on a chunk of the processor's silicon that is more privileged than anything running on the CPU itself. It's the exact same setup and will eventually cause the same kind of problems we see today with the ME.
Remember, it is possible to simply have two bad choices in front of you given the conditions one sets forth. Where there is a duopoly involved (in this case, Intel and AMD for x86 processors) simply using "the other one" doesn't always fix the problem you were wanting fixed...
Moving away from x86 entirely, on the other hand, allows these problems to be fixed. Can't do that? Then learn to live with the bugs and security problems. Might want to lawyer up too and start proactively filing patents on anything you consider valuable....
They would wouldn't they, as Intel put them there in the first place and wouldn't be currently reporting on this except Intel got found out by some third party who leaked that Intel had set the IME to login anyone with a zero length password and inserted a kill switch at the behest of the NSA.
I suspect it started off as a platform on which all the power management code could be run. The idea was that with the CPU looking after itself (power settings, cooling, voltages, clock frequencies, etc), you then wouldn't have to put all that code into the main operating system.
This was sensible, given that getting all that hardware management wrong could fry the silicon to a crisp. Offloading it to a separate microcontroller with a fixed binary blob meant that Microsoft, the Linux community, Apple, and every OS developer didn't have to do it themselves and get it right.
Then the feature creep started.
I'm sure that Intel's intentions where perfectly harmless. Being able to manage a server like you can (mount ISO images, see the console, all sorts of useful admin things can be done from afar) is incredibly useful. Just a shame the made a complete mess of it.
To be honest I can't see a way of implementing remote management of that sort without having an ME CPU bolted on the side with quite a lot of low level access. Though I don't see why that should need the ability to access all physical RAM, all Ethernet traffic, etc.
Though I don't see why that should need the ability to access all physical RAM, all Ethernet traffic, etc.
How else do you want the NSA to be able to intercept all network traffic from a box ? They need access to RAM to get the encryption keys to decrypt the Ethernet traffic ... d'oh!
Via the network controllers, which in the name of performance would likely have DMA access. This has the added advantage of being CPU-agnostic so should work with Intel, AMD, or whatever CPU is running the thing. It would also have the advantage of working with otherwise-open-source hardware since the technology behind high-speed low-latency networking is still patent-protected last I checked, making open-source network chips of any serious performance nigh-impossible to obtain.
"Being able to manage a server like you can (mount ISO images, see the console, all sorts of useful admin things can be done from afar) is incredibly useful."
First of all you're talking about desktop version of Intel CPUs that have ME, not server ones.
Second - what you're describing on servers called BMC ILOM and works at a totally different level and is usually separate processor running it's own embedded OS, i.e. Emulex Pilot, which now owned by Chinese ASPEED, so you should not be worrying about NSA anymore and start worrying about whatever their Chinese peer called.
And note that word "trusted"
Not in "we" can be trusted to run your applications safely,no.
You can be trusted to run only the content you have purchased.
This is at least as much about the hardware realization of Microsoft "Palladium" AKA "Trusted Computing Initiative" as anything else.
The computer hardware equivalent of "The Manchurian Candidate."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
