Seeing this reminded me of something that happened a few weeks ago. I went to a conference where someone very high up in Intel came out to give a presentation what they were doing for security. A few things stuck out to me:
- They said they work very hard to work with Linux to make sure their stuff is compatible.
- The person also specifically called out that they work with BIOS vendors (and called out Coreboot by name, implying they work with them)
- They added that they intend to make sure all of the features are on every chip, and it included the Intel ME.
When the talk was over, the first question someone asked was: "Is there any backdoor on your chips?" After a bit of laughter, the presenter said of course there was not and (understandably) got offended by the question. I specifically asked why they don't allow people to completely disable the Intel ME, and I did not get a concrete answer.
Seeing the _remotely_ exploitable Intel firmware vulnerability makes me not think that question was so funny. I really hope Intel is held responsible for this.
We in high-assurance security knew they backdoored it when they were in the Trusted Computing Group with closed-door meetings with the NSA for tech suiting their needs. Microsoft, too. They wanted to say security was purpose but we were pretty sure some backdoors and DRM would be in order in exchange for some payout. Also resulted in some special "high-assurance platform" tech that wasn't high-assurance (unlike pre-existing products), had to stay secret, was supplied by NSA, and would be in products people trust secrets to. Products running stuff like RHEL and VMWare. Oh yeah, that sounds legit as hell...
Then, I see Intel offer vPro/AMT with a networked, DMA'd microcontroller that listens for remote requests when the system is powered off and can bypass all security without host monitoring. Told everyone that would listen "There's the backdoor. They even said it publicly with different words but it's definitely rigged with a "un-avoidable flaw" with remote access. Or 0-days in rushed, complex firmware." Some security people here argued endlessly on some threads over whether the rand instruction was weakened for NSA on a chip with publicly-advertised, remote access to internal state. I mostly threw my hands up on the topic recommending PPC and SPARC most of the time with their Open Firmware if not custom stuff. Do embedded boards for management since they're cheap and can be isolated.
ECC RAM is a bit of a hard case in that the memory controller needs a slightly different wire protocol for ECC vs. non-ECC DIMMs. "Back in the old days", this was one of the justifications for having a northbridge separate from the CPU. Now, in the name of efficiency, it's all on-chip, making ECC a processor feature rather than a motherboard feature.
That being said, it'd certainly be possible to fix this: just ask RAM manufacturers to make their non-ECC memory have the same pin out as ECC memory, with the ECC pins just stubbed to always report that everything is okay. Then all processors could just include the ECC version of the memory controller.
While not exactly what you were suggesting, DDR4 ECC DIMMs and SO-DIMMS are already "pin compatible" with non-ECC modules. So it is straightforward to design a CPU and motherboard that support both, with a control bit in the IMC allowing the BIOS to enable/disable ECC checking (and the extra ECC byte lanes) iff ECC modules are installed (and that's what AMD did with Ryzen).
It is fair to say that Intel blocks ECC on its desktop i7 parts for non-technical/business reasons (i.e. so they can sell a higher-profit E3 Xeon if you want DRAM data integrity beyond what non-ECC memory can provide).
All processors do included the ECC version of the memory controller. Perhaps you're thinking of registered memory, which isn't supported by consumer-grade processors or the workstation/low-end server processors that use the same sockets?
This is not accurate, all (modern) AMD processors can work with both ECC and non-ECC ram, and ECC and non-ECC can even fit into the same ram sockets (the keying is different however, but a board can be compatible with both)
And yet the Pentium G4560 -- one of the cheaper models of their Kaby Lake lineup -- supports both ECC and non-ECC RAM. I suspect the only reason behind lack of ECC support on their mainstream processors is just market segmentation.
Like it or not, IMO there is little reason to expect this to have a material effect on the stock price, as it is not a product recall, and it probably will not seriously impact Intel's competitive position (given its main competitor is doing something similar).
+0.5% after opening. So the market apparently doesn't care one bit about this. And as long as the mainstream press doesn't care about issues like these that will probably remain so.
Yep. Of course us tech people would like to see Intel punished for ME but the market really won't care and that's the only thing that would push Intel off this path.
No doubt. It doesn't take long to find my own HN comments long before this story openly speculating that if the IME wasn't intentionally a backdoor, it had been made into one.
I also wonder how the timelines of IME match up with respect to the Clipper chip controversy as well, for that matter.
Wow. A _remotely_ exploitable Intel firmware vulnerability? You don't see one of those every day. My instinctive reaction is that this is ridiculously serious, although I'd need to see the full technical details.
It's worth noting that the reference to "system privileges" being attained likely refers to something much more privileged than we would normally ascribe to "system privileges". Normally, "system privileges" would mean something SYSTEM on Windows or root on Linux. In the event of "system privileges" in the management component, remember that the main CPU is a slave to this thing.
... Here we are, with an exploit that only affects people that enabled a remote management feature. If Intel had made this an optional addon that required a physical switch to enable, approximately the same number of people would be affected today, since it requires provisioning. It's not like every Intel system is silently waiting for an exploit payload.
Pretty much every large company running Intel hardware on professional desktops will have AMT on. It's pretty much SOP unless you really like site visits.
... And those companies would turn on the feature or get an equivalent third party system with the same attack surface. This doesn't seem to affect anyone that is against AMT.
You can't really easily opt-out of ME, which is the real problem. The fact that AMT has sprung a leak was only a matter of time but I'd rather not have the whole ME business.
I read about this a while ago. Apparently Intel's Management Technology which is built into like every Intel CPU now listens directly on the network interface so it can still send/receive data in case the OS is borked. It hooks in at ring 0. Like a rootkit the OS can't see.
It's common in the datacenter to come across motherboards with a switched eth0, with the BMC behind one leg and the user system behind another. You don't have to get that creative to get IPMI out of a machine when the OS is hosed -- to be honest, I think that is what you're actually thinking of, because "hook[ing] in on ring 0" is difficult to imagine working. You'd need driver awareness for when the management plane wants to transmit, at the least.
Not just SANs, pretty much their entire product line. iLO is a very common IPMI deployment at companies with HPe gear, which is a number of very large ones.
It's pretty much standard at large companies to never bother running the installer on the machine (if it even has one and isn't procured without an OS) they bought but instead to use a provisioning tool to re-image the machine before it first gets booted. Think of it as a DRAC card with some fancy tricks in a regular desktop (or laptop) and without occupying much space or a slot.
> only affects people that enabled a remote management feature.
The AMT can't be completely disabled, so people might not have to explicitly enable it to be vulnerable to AMT exploits.
> It's not like every Intel system is silently waiting for an exploit payload.
It's not like it's Intel makes it easy to navigate their CPU and motherboards feature set. Manufacturers are also known to do a bad job on their BIOS/EFI. And given that the computers most likely to be vulnerable are those most likely to be used by businesses and professionals, the damage potential is pretty staggering. But yeah, netbooks are probably safe.
It looks like this also affects systems where the feature is not enabled, but for "local" attackers. Does that mean exec as "www-data" or "nobody" accounts (what about VMs?). Making every little wordpress plugin vulnerability into a CPU-rooting hack?
Hey Michael, that's pretty amazing you have audited an encrypted and closed source binary from Intel to discover each Intel chip doesn't listen for an exploit payload. Would you mind sharing the keys you used to decrypt the firmware or the techniques you used to dissemble the binary back to the source code?
It was predictable, and I'm certain predicted by many.
These AMTs/MEs/whatever they call them are full-blown computers with non-trivial firmware/software. The question is: do Intel and AMD put all that much effort into making that secure? (That's quite aside from the possibility of intentional backdoors, which one would think would be reasonably secure so that only NSA and friends could use them.) The answer is "almost certainly not enough effort". This sort of device calls for using Coq or similar provably correct software construction -- it is much too critical to do otherwise if you're going to make it impossible to disable these things.
I guess we just have to filter these ports for a while now -- a big hammer for a big problem.
It's also time for customers to insist on these things being off by default.
The equivalent of ring -2 privilege. Below the OS or hypervisor level.
The intel remote control firmware is a rootkit that lives on many many systems for which the full features and capabilities of, along with all vulnerabilities, are kept as trade secrets.
"Traditionally", Ring -1 is the Hypervisor your kernel is running in, -2 is code running in SMM (e.g. BIOS USB legacy support code), and -3 is the firmware on your physical system (chipsets, hard drive firmware, etc).
The main CPU is no longer the "main" CPU. And before you ask, no you can't run your instructions on the real "main" CPU. Whose computer is it now? I went to Linux because of Sierra and things like Windows unavoidable "instrumentation" (whose OS is it?). Now Intel hardware is putting off that "you don't actually control me" vibe :(
My favorite part is the huge disclaimer at the bottom:
INFORMATION IN THIS DOCUMENT IS PROVIDED “AS IS” IN CONNECTION WITH INTEL® PRODUCTS. YOUR USE OF THE INFORMATION IN THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. INTEL RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE
Intel: "Hey everyone it's your BFFs at Intel. There's this uber critical bug in our enterprise hardware that will murder you right in the face and you should totally update your firmware right away or face certain doom even though we won't tell you exactly how it works or why it's so critical. Trust us, you totes need to do this asap but if it borks your servers ¯\_(ツ)_/¯. kthnxbye"
> even though we won't tell you exactly how it works or why it's so critical
This is their entire argument for the ME. Seriously, try to find deeply technical information on the ME. You can't. It's not public.
The best you can find are some books about the ME, written by former Intel engineers, who are still shockingly vague about what it actually does. Most "technical" books on the ME just repeat the Intel marketing drivel with marginally more (although still completely useless) technical detail. [0]
I've read some books on the ME because I wanted to understand better what it did. All I got was it has some magic sauce for content owners who want to DRM the heck out of their content, and it can emulate a TPM for OEMs who are too cheap to spring for a hardware TPM (although I've never actually seen this done).
It's beyond pathetic that we're scrambling for rumors on hacker news to figure out if we're affected by this. Security news is in need of serious consideration.
I had an interesting experience with the AMT technology fairly recently. I had updated my desktop's windows partition from Win7 to Win10 when it was free to do so, and then gone back to Linux. And because some tax information was in Quickbooks I booted it into Windows mode and it was trying to update to the latest Win10 and failing. I checked with Microsoft support and they had me download a tool to allow them to fix it, which kept failing to work. Eventually I tracked it down to the fact that I had previously disabled "Intel Management Engine Interface" in my device manager (back when there was a lot of discussion about it). Re-enabling it allowed their tool to loot through the system and fix what ever bits had given the OS fits, and then once it was running and current again, I disabled it again :-).
Based on the Intel documentation, my Surface Pro 4 is vulnerable (its a 7th gen with 11.6.0.1042) but its also disabled and I'm not sure whether or not that 'saves' me here (as the driver in the OS is disabled but it is unclear if a local network attack would work or not).
It says on the page "This vulnerability does not exist on Intel-based consumer PCs." I'm not sure if that's true or not but Intel seems to think you'll be ok.
EDIT: Ok so it seems all Intel CPUs that have AMT from Nehalem processors to the current Kaby Lake's are vulnerable. Even if AMT isn't enabled, it's still vulnerable to a local privilege escalation to ring 0. So all you people that have Celeron or AMD CPUs and got picked on for years, enjoy your moment of schadenfreude.
"It says on the page "This vulnerability does not exist on Intel-based consumer PCs." I'm not sure if that's true or not but Intel seems to think you'll be ok."
One thing to remember is that hardware costs money each time they instantiate a new mask set. Integrations cost money, too. That's on top of developing the individual components. So, a common trick in the hardware industry for a product family is to create one product that pretends to be several with a factory switch. Two examples come to mind: hard disks; mobile SOC's as embedded chips. In hard disks, there was at least one instance where vendor had same highest amount of space on all the drives with a switch saying how much to present to user based on what they paid. More profitable since mass producing one platter was cheaper. Another was in machines that people thought wouldn't connect to anything since they just had standalone-ish ARM chips. They actually had wireless functionality one could turn on with the right code. The ASIC guy that told me said he determined with was a chip used in cheap, mobile phones that they probably had a volume deal on and/or surplus. So, they just changed the firmware or something to make it pretend to be something else without notifying users.
Intel's stuff costs vastly more to mask out and verify than the above examples. That means they probably reuse silicon for anything that ends up in a lot of processors while turning some of it off with hardware or firmware switch at factory depending on what people bought. We can't know if any of this remote access is similar. That means that, if you don't want that, you can't trust any Intel CPU's made after that was introduced. Back to buying used multi-CPU boxes with 3GHz P4's. :)
Note: The PowerPC Amiga's like MorphOS suddenly look like they could have a purpose. Beautiful desktop with good performance that's probably not backdoored. Yet.
A big problem is that you cannot trust that the bits you don't want are irreversibly fused off and not just left disabled by the current microcode/firmware. Intel once sold a software switch to enable more L2 cache on a low-end CPU, so you really can't presume that any of their product segmentation switches are truly permanent once they've left the factory.
When Intel indicates that my B250 and Z270 chipsets don't support AMT, it's still quite possible that the ME firmware on those motherboards has the vulnerable code present but not currently running.
In that case, one has to spend extra money on ChipWorks tearing it down to verify that what they saw in other one was removed. There's also companies that sell such equipment.
I have a feeling we'll all know soon enough the exact definition Intel uses for "consumer PCs" and how it differs from the reality of what consumers end up buying.
They're probably referring to which chipset is on the motherboard. AMT is not supposed to be enabled on Z series chipsets but is on Q series, for example. But even on a Z chipset board, you still have Intel Management Engine (ME) firmware.
I know! I have a thinkpad with a 3rd gen core i5 and it has AMT. Once this exploit gets out in the wild it would be only a matter of time before it expands to other Intel CPUs with AMT.
That was what prompted me to post, I didn't think anything used it so I had disabled it on my consumer PC. Only to find later that at least in some situations it seems to be used on "consumer PCs". If I had documentation from Intel on all of its capabilities and uses I might feel better about it. :-) (or not)
To be fair, the original post is coming from an AdmiralAsshat.
What can anyone do? This corporate free-for-all seems like it's established (de-facto) in the United States, and all countries must bow to the US because of their military might.
We pollute, consume, lie, steal and cheat each other like it's normal practice. Where did we go wrong.
To be fair, some (most?) of the advances wouldn't have been possible without economic competition between manufactors, but closed source/closed design/closed production is bound to produce result like these. So, i don't know... Tradeoffs?
I was just doing some research on Intel Management Engine (ME), the independent subsystem on which AMT and other security applications run. Since I have them at my fingertips, perhaps these will be of use:
* By far the best place to learn about ME and AMT that I found, though it's a few years old:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine by Xiaoyu Ruan (security researcher with the Platform Engineering Group at Intel). Apress (2014)
* Intel x86 considered harmful by Joanna Rutkowska, founder of Qubes (2015)
Thankfully this doesn't look quite as serious as the SemiAccurate article earlier today made it look (it's AMT, not ME), and doesn't affect consumer CPUs. But if you have AMT provisioned, then holy cow this is really really bad. Remotely exploitable is just wow.
Agreed, it's still very bad. I don't want to imagine how many company PCs are affected by this, and which percentage of those is going to get the firmware update.
No, that's not the same. Imagine ME being exploited, that would open up the system regardless of whether or not you even had AMT, installed or enabled. That would be a far more serious issue, the number of systems affected would be a very large multiple of the number of systems affected by this bug.
No, it does not. Again: VPro is not in all Xeons (though it is in many of them, and it is in most or all of the current product line), AMT is in only very few Xeons.
If VPro were in all Xeons then each and every Intel based computer in a DC would be affected. And that's clearly not the case. Also, it is not yet clear - at least to me - whether or not VPro is affected at all but if the ME runs AMT then it definitely is affected.
The 'only 2' are about which Xeons I've found that definitely run AMT. That's something else. Intel isn't helping with their marketing spaghetti, but you're also not helping by suggesting that each and every Xeon is affected.
Though if that is the case Intel has a much more serious problem on its hand for suggesting that only business desktops and a couple of low end servers are affected.
> Considering how right SemiAccurate was already today, I’m inclined to believe him that vPRO and co are affected.
Well, he was 'SemiAccurate', not accurate so you have all the reason to believe until further notice that VPro is not affected by this bug and claiming different is like shouting 'fire' in a crowded theater. Absent hard proof I don't think you should make such claims. Though I'm sure most sysadmins here would know the difference between a legitimate claim of such magnitude and an inaccurate one.
SemiAccurate got the gist right but lots of the details wrong.
> Well, he was 'SemiAccurate', not accurate so you have all the reason to believe until further notice that VPro is not affected by this bug and claiming different is like shouting 'fire' in a crowded theater. Absent hard proof I don't think you should make such claims.
Considering the fact that people claimed a few hours ago AMT would be entirely secure, I think the opposite should hold true right now. Assume everything is vulnerable, unless proven otherwise.
This is standard practice in most of IT, but apparently we ignore it here.
> Considering the fact that people claimed a few hours ago AMT would be entirely secure, I think the opposite should hold true right now. Assume everything is vulnerable, unless proven otherwise.
Well, in that case you'd better disconnect from the internet don't you think?
AMT was not claimed to be 'entirely secure' by anybody that mattered as far as I'm aware and Intel is pretty explicit about this vulnerability. It is a bad one because it is a remote exploitable one, but it isn't the first vulnerability either.
> This is standard practice in most of IT, but apparently we ignore it here.
Standard practice is to go on facts, not on conjecture or hype. If VPro rather than AMT is exploitable that would be very big news, far larger than the issue currently being reported. So far I have not seen a shred of evidence for that but who knows, that might change and then it will be a very very long night for a lot of people here. For now though there is no reason to be so alarmist.
Also, I'm kind of done with this discussion, you seem to want to hold on to a rumor on a website calling itself 'semi accurate' which in fact was exactly that and for which I'm grateful to them. But they are not authoritative in any way and you should stop making it seem as if they have the last word on this, if you want to make a point show some proof.
VPro or not doesn't matter, if the ME runs AMT then you might be affected if the version numbers are the ones listed in TFA so that's what you should go on, not just on whether or not you have VPro.
And if you don't need it disable this stuff in your BIOS, no need to enlarge your attack surface without a reason.
That selects for VPro, which is not the same as AMT.
Note that the Intel advisory does not list VPro. If that is the case then tomorrow would be a really good time to buy some AMD stock, there would be very very large numbers of Xeons affected.
But the Intel advisory specifically links to this document[1] to assess your exposure, which just says to look for VPro. The info out there is still garbage at this point, but that seems to be the most authoritative I've seen so far.
Interesting. So, AMT being a part of VPro might have warranted the inclusion of that term or the term 'Xeon' with a list of SKUs in the original advisory or something if they are affected. Right now it reads as if the server side is a-ok except for some rare beasts, so that's what I'm going on until there is evidence to the contrary.
I'm halfway tempted to call my sysadmin out of bed to check one of our systems that I'm quite sure has VPro to see if it is vulnerable. Fortunately my main server is an AMD Bulldozer box.
Regardless, if it runs AMT you should check it, VPro or not is really besides the point, it's AMT that is the problem, not VPro as such, which is just another marketing term for the ME and application suite if I understand it correctly, and if that were exploitable instead of 'just' AMT it would be much bigger (and worse) news.
But saying that all VPro enabled Xeons or even every Xeon is affected is needlessly alarmist.
If you look at the list of version you can see they all target Desktop and Mobile, no Xeons besides the one I listed earlier. The document you linked also explicitly states 'PC's', not 'servers', though it is definitely possible that some hosting facilities use (cheaper) desktops as servers.
Well according to the all knowing wikipedia only the Xeon E3-1200 product family has AMT and would be vulnerable. So your servers should be ok, but most every desktop and laptop on your network with an Intel processor from the past 10 years, not so much.
I thought AMT was a component of VPro. I assumed all VPro systems had it based on early marketing of the management capabilities of VPro. They were just bundling management and security features. Memory too broken to be sure but that feels like what I said to a lot of people over time.
It's rather unclear whether this exploit is related to the one the SA thinks they have found, and at the time SA published their article it was unknown whether any actual exploit existed--the only real public information that SA had in their article was that Intel had distributed a new firmware.
Fiora Aeterna posted this about SemiAccurate on Lobsters with a hilarious part about the effect of triangles on SIMD used in graphics pipelines.
"Semiaccurate is well-known for posting speculation as fact, but worse, they often have major misunderstandings of the material they report on, leading to errors, incorrect deductions, wild speculation, etc. My favorite example (a real quote, not satire):
'You probably don’t remember but the Midgard architecture you know and love is a four wide architecture four stages deep. Each cycle one thread, aka a triangle or quad, is issued to the execution units. Since they are four wide they can take a full quad a cycle which is a really good thing. Unfortunately most game developers seem stuck on triangles which tend to use only three of the SIMD vector lanes. This is bad but modern power gating means it won’t consume hideous amounts of power, it just doesn’t utilize the hardware to its maximum potential often. The technical term for this is inefficiency.'"
Waaat? I read that quote a few times, and I still can't tell what it's trying to say. Is it saying triangles as the basic building block of 3d objects is used as a way to power gate certain cpus that supposedly have better support for squares because they're "four wide"? If so, then yes I agree who ever wrote that has no understanding of what they're talking about.
The "too reliant on triangles" is the first hint. As if the game and GPU industry are full of idiots that don't know the fundamentals of their field. Then, a triangle utilizes three lanes of SIMD. What, because it has three sides it uses three instructions? Or is it the GPU drawing those things? And lets see what StackOverflow might tell us if we were the authors researching quads superiority to triangles for gaming:
If AMT is enabled it would be listening on ports 16992 and 16933 (TLS). I ran lspci | grep MEI on my machine (an i3-2100, not vPRO as far as I know, running Linux Ubuntu 16.04) and got:
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
Then ran nmap -p- and the ports didn't show up, and can't access them, so AMT is disabled. You can read more on how enable or disable AMT and how to access it here:
2009: "The underlying technology that performs a remote power on command [for AMT] uses the http transport, either port 80 or 443" | https://communities.intel.com/thread/2888
- Ylian Saint-Hilaire, Principal Engineer at Intel
Yes. This affects the management engine, an independent firmware that runs in your system wether it runs linux, windows BSD. It is still running even if your computer is off (in fact, one of its capabilities is to turn it on remotely).
Edit to add: independent of what Intel might say about this (given it seems it has taken 5 years to disclose this and 5 major firmware versions I won't trust too much what they say about consumer pcs not being affected). Check if your cpu and motherboard support AMT and if it is enabled. All workstations I've worked with have it, but there are a lot of machines that have it disabled by default unless you specifically turn it on. So, you might be affected if you have a "supported" processor and (I guess) an Intel NIC onboard and wired, and remote capabilities enabled.
I'm mostly interested in if servers with ipmi (supermicro in particular) are vulnerable, and to what degree. If it's the network with the ipmi ports, that's one thing, but if it's public facing...
IIUC the SuperMicro BMC is different software on a separate third-party chip. So it's reasonably likely to be vulnerable, but not to this particular vulnerability.
Yeah, that's pretty easy on this generation. But there was a previous generation where the IPMI piggybacked on one of the main NICs, where it was a lot easier to accidentally expose that to unfriendly traffic.
Are you sure? Both my ThinkPad (personal) and my MBP (work) appear to be affected; they report CPU models that, when I look that model up in Ark, Intel says has the vPro technology.
It seems that for network management vPro needs a compatible CPU, motherboard chipset, and a Intel ethernet controller. So in theory Macs are safe from remote exploitation?
What will really be interesting to see is if this is exploitable via PCIe for local privilege escalation on consumer processors with vPro.
> It seems that for network management vPro needs a compatible CPU, motherboard chipset, and a Intel ethernet controller. So in theory Macs are safe from remote exploitation?
If that's the case, that sounds to me like there is special code in the Intel NIC firmware to allow/forward/do things with these packets?
I think we need to remove the word 'conspiracy' from the English language, it's been abused too well by propaganda.
I thought I might be safe with an APU-2 device as a firewall (AMD chip, don't know if they have the same arrangement with the five-eyes), but Intel NICs.
Guess the motto is, use paper and lead pencils for anything really important. And turn wifi off.
These scumbags are actively ruining computing. Cars, bridges, infrastructure... can't these warhawks pick on something else?
Then you get the NSA, the ASD, the rest of the clowns coming in and ruining it, and what is the point? Are we all just fighting each other in an ape war?
AMT is a part of the vPro management suite. All 3500 of our desktops had AMT at the school I worked at. They did not, however, have vPro. Having it was as simple as paying extra per machine. I would guess that it's in all of their CPUs, just disabled at different levels depending on the OEM and the system you order. Typically, you will not find this enabled on consumer desktops / laptops, but a lot of the business ones at least come with AMT, even if vPro does not.
The Linux kernel modules are mei_me and mei.
To check:
modprobe -nr mei_me mei #dry run
modprobe -r mei_me mei #to unload the module
This will not persist across reboots.
There is also a lms package.
I don't know whether any of this is required for a remote exploit, or if it's only needed for local escallation.
From my understanding, this exploit can work regardless of the operating system. I mean, if this Intel hardware can get network packets without the operating system being aware, then not having those modules loaded won't help.
Doesn't intel provide firmware that can be downloaded from kernel.org? If this is included in that you can A) wait for it to be available there and recompile your kernel or B) wait for your distro maintainer to update your kernel.
If you load firmware from userspace you can probably just put it in the directory the firmware helper searches.
You're possibly thinking of microcode for the x86 CPU.
This vulnerability is in code running on an entirely different processor that resides in the PCH on the motherboard and is initialized from the flash ROM on the motherboard long before any OS boots on the x86 CPU.
Yes, which makes it really annoying because the one thing you want to know is how you can see if this has already been exploited which is the difference between a system wipe and just a firmware upgrade.
I would truest the message "has been exploited" but not the message "has not been exploited". Who could state the latter with any sincerity? Intel could do state this only with confidence if they'd monitor every of their systems sold, which I sincerely hope is not the case. If you have vulnerable, critical systems you need to consider them being exploited. The bug was there for years and for all what we know at least state actors have been going to great lengths to exploit vulnerabilities they could get hold of.
It seems like everyone in the security community saw this coming. I hope this serves as enough of a warning to, at the very least, get Intel to stop putting spyware in all their CPUs. Ideally, this helps push large hardware manufacturers away from proprietary CPU manufacturers entirely. Open source hardware collaborations could (and should) do to Intel what open source OSs did to Microsoft. Doesn't mean that Intel will go away, but their presence should absolutely be reduced.
The spyware is there due to customer demand. All the biggest customers of Intel buy in vast quantity and need these features for their fleet management. It ain't going nowhere.
I understand what those customers need AMT for but the end result is that somebody else could be managing their fleets too and this is not something they want.
vPro is Intel's marketing term for a bundle of stuff including AMT, so "business" PCs have a vPro sticker and "consumer" PCs don't. It may be hard to tell if you already peeled the sticker off, though.
For Mac, I did this. Please anybody out there, confirm whether this is a legit approach. From a console I put:
sysctl -a | grep -i intel
There should be a bunch of noise, but in there was a rather specific model number (not just "core i7"). I googled for that and found a page on ARK. Look for "vpro" and it should say whether you have it. (I didn't)
I can't confirm whether your approach is legit (though vPro does seem to be relevant), but I find my work machine (2015 15" rMBP) has it, and my personal (2013 13" rMBP) doesn't.
Specifically, the string you want to `grep` for is "machdep\.cpu\.brand_string".
> Starting to believe me now that far more systems are affected?
No, that system still falls under Intel's advisory, it's just the Lenovo page that doesn't help to distinguish. It was already known that laptops could be affected.
Your claims were about 'All systems running VPro' and 'All Xeons'. Neither of those claims has - so far - being substantiated, the only Xeons affected are the ones - though there may still be more - that I dug up earlier.
Really, you should let this go or come up with actual proof for your claims it is getting annoying. You pollute this whole thread with a bunch of unsubstantiated claims presented as fact. It's almost as if you would love for it to be true that all those other systems would be affected too.
Don't get me wrong, I'm very much against ME and any non-free software on my machine starting with the BIOS but I'm also not going to wish for just about every server on the planet to be remotely hacked just to prove my point.
> I'm also not going to wish for just about every server on the planet to be remotely hacked just to prove my point.
Well, it's not about proving a point.
It's about what comes after that.
And I wish that we don't waste centuries of programmer-years of work onto systems that we'll end up having to get rid of anyway. I don't want to see society build on top of something that ends up with such a destructive potential.
At some point it will be broken, every system using it will be hacked. We'll see something like Mirai, but on far larger scale.
The only question is if we've migrated the critical infrastructure by then, or not.
Yes, but you're actually working against this. By claiming something absolutely HUGE is happening when it isn't you are aiding the opposition who can then say 'see, you were wrong all along'.
What really did happen is already bad enough and deserves all the attention it gets without people muddying the waters claiming the issue is larger than it really is. That's dumb propaganda and easily dismissed. It also takes the attention of the real problem.
So if you're serious about this then you should concentrate your advocacy on those things that you are sure about and that you can prove. That will move the needle. Speculation is only so much noise on the wire, easily drowning out the real, facts based conversation.
We have zero information about the vulnerability, other than that it allows unauthenticated access to AMT. One big thing that's not clear at the moment is whether this affects all AMT setups, setups that are in Small Business Mode, or setups that are in Enterprise Mode. If the latter, the impact on individual end-users will be basically zero - Enterprise Mode involves a bunch of effort to configure and nobody's doing that for their home systems. If it affects all systems, or just systems in Small Business Mode, things are likely to be worse.
> What should I do?
Make sure AMT is disabled. If it's your own computer, you should then have nothing else to worry about. If you're a Windows admin with untrusted users, you should also disable or uninstall LSM by following these instructions.
And that's a good part of the reasons I'm categorically against any 'rider' computers next to the one that I control. It's hard enough to keep a regular system secure, if you have to factor in ghost computers that are effectively running with a privilege level above your local root then the situation becomes untenable. Intel really should allow for a simple way to turn off all this bull-shit without any way for it to be remotely re-enabled. And without any crippling effects on clock frequency or power management or networking.
Many people wrote that ME was a potential vulnerability and backdoor along the years. Russia and China have been designing some CPUs for a while even if they are not at the same level of Intel and AMD yet. I remember Russia's Baikal (MIPS and ARM), China's Longsoon (MIPS family) and some ARM chips. I wonder if they planned those chips with national security considerations in mind.
The current trend of blocking some Internet services with country level firewalls could be another way to protect from remote attacks. At least spies should spy from within the country as in the old times. They could see the other effects as bonuses (political control, protection of local companies) and being large countries thay maybe don't care much about the consequences of a slowed down information flow.
Merely having a "vPRO" CPU and chipset isn't sufficient - your system vendor also needs to have licensed the AMT code. Under Linux, if lspci doesn't show a communication controller with "MEI" in the description, AMT isn't running and you're safe. If it does show an MEI controller, that still doesn't mean you're vulnerable - AMT may still not be provisioned. If you reboot you should see a brief firmware splash mentioning the ME. Hitting ctrl+p at this point should get you into a menu which should let you disable AMT.[1]
Luckily my old rack is too old to have ME. But are there alternatives out there when these old power-edge warriors finally die or do I have to start building a beowolf out of raspberry pis?
There is OpenPOWER, or ARM. Unfortunately all new Intel chips have the Management Engine, and all new AMD chips have the equivalent Platform Security Processor.
> What was Intel ME trying to solve that couldn't be done without it?
ME is an independent platform that runs parallel with the main CPU. ME has it's own CPU, memory, bus, etc. The general purpose is to provide an isolated subsystem on which to run security and management applications.
AMT's out-of-band remote access allows support to access the computer when the OS isn't or can't be loaded.
From the IT and security perspectives, these features are very valuable.
I'd very much not bet on this being the only or the last bug. See it more as a confirmation that this system is not as secure as they thought it was and that will cause a lot of people to now be encouraged to look at it closer.
> confirmation that this system is not as secure as they thought it was
I wonder if that's true. Intel has many smart security professionals working for it, and probably they expected there would be exploits; they exist on every system. I'm reading a book about Intel Management Engine (the independent subsystem on which includes AMT runs) by an Intel engineer[0], and they are clear that their model mitigates risk but nowhere do they say that it's invulnerable. In fact, they include responses to exploits in their discussion of their security process.
It's as secure as I thought it was; of course there are some vulnerabilities. The real issue to me is how effectively they mitigate it.
[0] Highly recommended to learn about ME and AMT: Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine by Xiaoyu Ruan, published by Apress (2014)
Systems like this ought to really be bullet-proof. You can do all you want to secure the other layers (the ones that you have regular access to), this one bypasses all of that and gives an attacker the equivalent of physical access to the hardware. To me that's a level above the kind of flaw that can be attributed to faulty system administration, operating system or application bugs.
It's essentially a monkey riding along on your shoulder that suddenly turns out to be malicious.
To me these systems are accidents waiting to happen. And this won't be the last bug either, you can bet that AMT and ME will receive a lot more hostile attention than they got so far in the next coming months.
Some of their competition have gone through the trouble to create or buy high-assurance security for such purposes optionally with the code written in languages like SPARK provably immune to errors hackers go after w/out runtimes. This approach goes back to the 70's-80's with modern tools super easy and cost-effective. I mean, a handful of people at ETH made the Muen separation kernel with a similar handful doing a high-assurance VPN at Navy Research Laboratory. There's companies that would do it for them with whatever mix of robust or complex they want.
They just don't give a shit. Like you said, systems like this ought to be bulletproof. I'll add it's especially true when they're in most of the products of a company making hundreds of millions to billions off them. Even small-to-midsized firms are doing medium to high assurance designs. I'm sure Intel could afford it. ;)
Do their customers want high-assurance? As I posted elsewhere, corporate IT is sophisticated enough to know the risks, and they chose to enable AMT widely. Does the level of demand make it profitable enough to justify doing? Personally I would pay a good amount for high-assurance systems - or even subsystems, as in this case - but my budget isn't unlimited. More than a small cost would be hard to sell to management, which as we all know often budgets little attention to security, much less money.
OTOH, there is a good argument that vendors know the risks much better than their customers can, and that they have a responsibility to protect their customers from dangerous options. But even that depends on the cost; everything can be made safer for greater expense. I wonder if this qualifies.
Their customers prefer highly-privileged code not get hacked vs get hacked. Intel knows their dominant position with lockin to x86 code lets them ignore customers' preferences if they deliver something useful. It's an oligopoly effect.
It's actually AMD I normally suggest should compete on flexibility or security. They need the money more. ;)
Sure they prefer it. I prefer a soup-to-nuts high-assurance personal laptop, or a private 747, but I'm not willing to pay for them. I know my laptop can be exploited. My point is that it's an economic question, not one of technical specifications.
> Intel knows their dominant position with lockin to x86 code lets them ignore customers' preferences if they deliver something useful. It's an oligopoly effect.
To a degree. Customer could use their TPMs for many of the same functions as ME, or get third party devices for out-of-band remote control like AMT. Intel just needs to make it good enough, but that's the 'intentional', so to speak, design of marketplaces.
I would love it if AMD took the opportunity, and security became a competitive arms race between them.
It is economic issue. Unfortunately, the incentives work against it on supply side since they maximize profit even to detriment of users. The oligopolies universally supply garbage that suits them. If it's quality or security, customers often just get used to the problems. That lowers demand side. Differentiating firms can show up but will be niche unless latching onto something big. I thought about Java, C#, or Go CPU's at one poing for application servers. Different front end with safety/security checks on top of high-performance design probably. Can't be sure on economics of it, though.
Everyone who sells systems knowingly sells exploitable ones, unless the sellers are naive. Every system you and I deliver to our customers/users is exploitable.
And knowing that I'd never be naive enough to embed it in every CPU I made since 2009. Not to mention allowing AMT to exploited even when it's disabled, and not share the source code so it could be properly audited. Every decision Intel made points to either them thinking this system was bulletproof (at least at the upper decision making levels) or they're so incompetent they shouldn't be trusted with anyone's security.
Corporate IT seems to disagree. Certainly they are sophisticated enough to know the risks, and they enable and use AMT widely.
Personally, I hesitate more than most because of the technical reasons you cite, but even turning on a computer is a risk. Probably this isn't the greatest risk to a business' IT.
As somebody who consults with Corporate IT, more often then not I run into the mindset "well if every other company is taking on the same risk then it's a wash". Aka disabling SELinux is what everybody does, we aren't taking on any more risk than anybody else (and it'll make us more competitive because we can iterate faster), so why not? Very few companies think of security as a feature, because so few consumers think of security as a feature.
I agree completely, many many companies are totally fine with accepting that risk due to the trade-off for ease of manageability. But I'm really not, in no small part because the overhead to managing a few computers is totally different than a large corporation with thousands of machines. I just wish my vote counted to Intel (or AMD for that matter), and I could completely disable ME because I'd rather the more difficult management of machines over the much larger attack surface.
Of course it all seems to lead back to monopolies/duopolies being bad for the average consumer. Who knew?
This strikes me as an odd argument. Corporate America is notorious for not taking security seriously until it is too late. If you care at all about security you shouldn't take advice from what corporate IT is doing.
Retail POS could be bad news, but it got me to thinking of all the other possibilities too. Could be disastrous, and I wonder who would wear the egg on the face, Intel or the NSA :) Or no-one is my guess, too big to fail!
That's true, but for all intents and purposes NAT is a poor-mans firewall. Many people don't know any better or that's what keeps them safe, they wouldn't know the difference between multiplexing a bunch of machines behind a single IP using port forwarding and firewalling because if a port isn't forwarded it appears as if it is firewalled.
That's a legacy bit that a lot of people will have a hard time adjusting to when IPV6 becomes more mainstream. Basically every piece of gear in your house can have a routable IP under that scheme and then suddenly your edge router configuration becomes a lot more important.
I wonder if how much they have baked into IPv6, and what I would consider hard-to-read addresses (the hex form anyway), the "special" addresses etc, are providing a barrier to adoption.
They should have just expanded the address space in v6 (5?) I reckon (and maybe any warts from history that needed cleaning up).
Right but the default ruleset allows incoming packets for established connections, meaning your PC can still contact a remote host with malicious intent and be exploited.
> NAT is not a firewall. It's not intended to protect, and usually it doesn't
It's funny that this still needs to be brought up, but I understand why some people think that NAT offers some real protection.
Basically NAT makes it difficult (without setting up forwarding, etc) for non-malicious-you to reach a device that's behind one, ergo non-malicious-you believes that NAT is providing protection.
"If it's impossible for me to access a port behind a NAT it must be hard for everyone".
Of course the whole point of a NAT gateway is to poke holes in itself (indiscriminately) so that devices behind it can talk to the world.
I wonder what will happen when the whole world is on IPv6 and we don't need NAT anymore - is a consumer wifi router with an actual firewall going to be common, or are we still going to use NAT to "isolate" devices on our local network.
Personally I'm a fan of IPv4 only because I can actually remember the addresses - every time I deal with a v6 address it's copy/paste or bust - forget being able to verbally share the address of a thing.
Mind you I no longer do network consulting, so the only IP address I remember these days is 8.8.8.8. I guess it won't affect my work ¯\_(ツ)_/¯.
I asked because I would guess that the vast majority of devices that are potentially affected are behind NAT, and they are likely to be safe from outside threats until one is introduced through users or some other hack.
Nowhere was it suggested that NAT was part of the security strategy... which you are right, is a very bad idea.
The bits that are available right now suggest that someone has figured out how to jump the gap between the 'public' and the 'secure' networks. If that's true a NAT would not help once packets are forwarded.
It would really help if Intel came clean and indicated exactly what the exposure is here.
It's easy to think of ways to jump NAT -- port forwarding, UPnP, reverse tunnels, so on. To me the real question is whether or not this exploit can jump NAT without needing any of other hacks or techniques or (possibly unwitting) user intervention.
We need a service to monitor all the published security & privacy issues that vendors like Microsoft, Intel, and Apple don't consider to be bugs, and then offer some kind of automatic disable/fix/patch/uninstall tool.
I'd be willing to pay $50-100/year per system so I don't have to personally dig into every security and privacy mitigation.
Specifically, the tool or service should:
- Check for known vulnerabilities just like Management Engine described in the article, and disable it or patch it (if a patch is available).
- Uninstall or disable all tracking, reporting, spyware features (esp. in Windows 8 and 10 for example).
- Disable all unnecessary services to harden the OS. Yes, I realize that this has the potential to break things, so it has to be done intelligently.
- Etc.
I would have thought that anti-virus software would have been a perfect place to build in such capability, but AV software has generally turned into garbage unfortunately.
you kind of can't get to _all_ the things, but you can choose to approach the problem with containment. We are one option (see my profile) but there are lots of others.
IMHO the problem isn't known vulnerabilities checks and patches but the vulnerabilities you don't know. The problem is, of course, that it is very hard for most people to get to a default-closed model for their servers.
Ok, so you're Intel, and your business customers say they'd like to remotely fix their workstations via IPKVM and other stuff so they don't need to dispatch a tech each time someone wedges their laptop.
Someone suggests adding AMT to certain chips then charging to enable it. You say that's evil. Why and what's your suggestion?
With the details released so far, this isn't remotely exploitable unless your company set the feature up. And if Intel didn't provide this feature, you'd get it from the OEM just like Dell's DRAC or HP iLO.
What is evil is not providing a hardware lockout to disable it if you don't want that ME. AMT is only one application running on ME, there are others and the whole thing could be insecure. If you don't need it it is better not to have it.
Going with accident, Intel not taking care of a buffer. In my view, the malicious model would involve a 'special' asymmetric key that would let Mallory right through the front door, and we'd hear about it from someone like Ed or Julian.
I can buy that it's accident that this vulnerability exists. It's still gross stupidity/incompetence/negligence (/malice?) that this vulnerability ever had the possibility of existing. That is, the feature should never have been implemented, to prevent exactly this scenario.
In my opinion all hypervisor-like hidden chips should be always documented, and disabled by default, by law, except for closed appliances (e.g. a video game console). That's crazy and very dangerous stuff.
It talks about turning something off with a Windows executable. Was it necessarily on to begin with? Anybody familiar with this product? I thought this was a sub-OS level thing.
Its important to note, that Intel has a VERY strong incentive to downplay the seriousness of this problem. Other sources have indicated that its possible on any post 2008 Intel system, its just not possible remotely.
Since we don't know the exact nature of this exploit, things are extremely dangerous for ALL Intel systems right now.
I'm trying to find out if this applies to enthusiast processors that lack vPro. I purchased my chip with this in mind. Any information would be appreciated.
"There are several features that AMT provides that are present in consumer systems even though the ‘technology’ isn’t there. This is one of the arguments that SemiAccurate has had with Intel security personnel over the years, we have begged them to offer a SKU without the AMT hardware for just this very reason. Intel didn’t, the pressure to lock corporate customers in to their silicon was too high."
Intel is playing this down heavily. This seems to be locally exploitable on consumer chips. Correct me if that is wrong, please.
EDIT: I'm not one to give a shit about downvotes, but it would be nice if someone could actually respond to me with a legitimate retort instead of trying to bury this post. I am asking to be proved wrong for my own sanity. Let's be mature about this.
I have confirmed through ARK that not only does my chip lack vPro, but it also lacks TXT, which I hadn't confirmed before. I consider TXT to be just as vulnerable as AMT / ME.
Feels good to know my sensibilities paid off. Worth every dollar.
Now I just get to sit back and watch the shit show unfold :)
Basically you're asking us to prove a negative about undocumented proprietary firmware. Someone could spend years fully reverse-engineering ME firmware to prove these theories wrong, and then people would just say "but what about version N+1?"
Not really. The evidence currently points to all basically all commercial Intel chips in the last ~10 years being vulnerable to this.
In addition to correcting you about Intel's blatant lie, I was asking if anyone more qualified than me could confirm or deny whether it affects certain enthusiast chips that seem to lack certain vPro features.
My question was not about if consumer chips are affected, because they are if they have the ME engine. However, the enthusiast chips I reference supposedly do not even have a functioning ME system to reverse-engineer in the first place. Asking for confirmation of such by a qualified individual is reasonable and answerable.
Both GCP/AWS already probably have (or had, if they were alerted before public disclosure) security teams probing their internal systems to see if they're vulnerable, and install firmware patches. The danger is more medium-to-large organizations whose internal clouds and desktop systems are impossible to patch at scale.
Many Xeon SKUs include the Management Engine, which at times has seemed to share many of the features of AMT/SBT/etc, but its unclear on the exact attack vector for this vulnerability.
Having said that, the ME is so opaque, the same type of vulnerability could easily exist.
If remote management is used for servers, it's normally IPMI with a completely separate baseboard controller that has its own NIC connected to a physically separate network [although some boards cheap out on that, notably older INTEL boards, where the separate NIC is an option you have to buy].
For a system to be affected, both chipset and CPU have to support vPro. For example, a PC with Core i7-7700 CPU and H270 chipset is not affected because only the CPU has support for vPro, but a PC with Core i7-7700 CPU and Q270 chipset is affected because both CPU and chipset have support for vPro.
What is the network traffic for this management stuff? TCP? UDP? What ports? I presume just blocking it at the switch or router would be an approach to mitigation?
EDIT: from the PDF posted in another thread, looks like the Intel ME ports are 16992, 16993, 16994, 16995, 623, and 664.
It has to have the ME silicon and the AMT enabled firmware. According to Matthew Garrett, who I'd generally trust on this stuff, Apple hasn't ever shipped AMT-enabled firmware.
It's nice to see that for once it's a good thing that Apple hardly ever ships standard firmware and instead usually leaves out all the components and features they don't plan to use.
vPro isn't a CPU, it's a particular combination of CPU, PCH (southbridge), Intel NIC/WiFi, and AMT firmware. There's no evidence that Macs have AMT or vPro.
You're right about that. Intel's product lineup is a huge mishmash of optional features that no one understands and now it's going to bite them. (But not really, because what else are you going to buy? A Ryzen laptop?)
Is there any chance this could be exploitable from within a guest virtual machine, or does Intel's architecture only allow a hypervisor to communicate with the firmware?
If it is remotely exploitable that means that if you're on the network you can do damage. So if that guest virtual machine has access to the same LAN or VLAN that your ME sits on then you might be in trouble.
That's the whole problem here, this is an issue that allows a remote attack, not just a local one.
Step 1: Determine if you have an Intel® AMT, Intel® SBA, or Intel® ISM capable system: https://communities.intel.com/docs/DOC-5693. If you determine that you do not have an Intel® AMT, Intel® SBA, or Intel® ISM capable system then no further action is required.
Step 2: Utilize the Detection Guide to assess if your system has the impacted firmware: https://downloadcenter.intel.com/download/26755. If you do have a version in the “Resolved Firmware” column no further action is required to secure your system from this vulnerability.
This is just what you would expect would eventually happen with AMT. Frankly it should be possible to physically disconnect a jumper on the motherboard that completely PHYSICALLY disables things like AMT.
There is an undocumented pin which, when properly pulled {up|down} on startup, a.k.a. strapped, causes the ME to bypass its internal boot ROM and read from an external bus.
It is used internally to develop the ME and its firmware. It may not continue working after the OEM blows the last e-fuses -- it may be necessary to start from chips in the "partially fused" state that Intel ships out to OEMs.
A sufficiently motivated attacker, knowing it exists, could find it and exploit it. A sufficiently motivated defense, knowing it exists, could find it and use it to (re)gain control over their ME firmware.
The attackers have an advantage right now: currently deployed ME firmware is vulnerable. I'd like the defense to have all relevant information at their disposal.
> An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs
This appears to imply an "exploit $site-backend -> provision AMT -> be vulnerable to network/local attack (for provisioned AMT) -> get AMT system privileges" route.
That's a great idea for training an AI for, and someone totally has already done it. I'm training myself to (be able to) live off the grid when time comes.
- They said they work very hard to work with Linux to make sure their stuff is compatible.
- The person also specifically called out that they work with BIOS vendors (and called out Coreboot by name, implying they work with them)
- They added that they intend to make sure all of the features are on every chip, and it included the Intel ME.
When the talk was over, the first question someone asked was: "Is there any backdoor on your chips?" After a bit of laughter, the presenter said of course there was not and (understandably) got offended by the question. I specifically asked why they don't allow people to completely disable the Intel ME, and I did not get a concrete answer.
Seeing the _remotely_ exploitable Intel firmware vulnerability makes me not think that question was so funny. I really hope Intel is held responsible for this.