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.
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.
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.
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].
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.
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.
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 :)
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'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.
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:
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.
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.
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.
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?)
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.
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.
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?
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.
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.
... 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.
> 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.
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?
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 :(
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.
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.
> 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.
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.
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.
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.
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.
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).
> 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.
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, 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.
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.
> 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.
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".
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.
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.
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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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)
"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.
314 comments
[ 3.9 ms ] story [ 289 ms ] threadSince we don't know the exact nature of this exploit, things are extremely dangerous for ALL Intel systems right now.
Servers may be affected by the absolute shit firmware living in their Aspeed BMCs, however.
Having said that, the ME is so opaque, the same type of vulnerability could easily exist.
edit: E3-1200 as well, same kind of application, single CPU workstation chip.
No mainstream (2-way) server has AMT, anyway.
https://www.orwell1984.today/no_vpro_for_me.html
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.
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.
Feels good to know my sensibilities paid off. Worth every dollar.
Now I just get to sit back and watch the shit show unfold :)
https://news.ycombinator.com/item?id=14237266
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.
Closed source. It's a choice.
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?
In this case it really isn't and that is a huge problem.
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)
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.
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. ;)
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.
The intel management engine has and continues to be a security threat. And now everyone can see it.
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.
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.
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?
> I just wish ... I could completely disable ME
You might find this useful:
https://puri.sm/learn/avoiding-intel-amt/
Crazy. A lot of the HN discussion was incredulous based on SA's reputation. https://news.ycombinator.com/item?id=14237266
"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.'"
https://gamedev.stackexchange.com/questions/66312/quads-vs-t...
Am I vulnerable to this on a Linux System? If so, any way to assess vulnerability, and patch things?
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.
Much stuff is going to be hitting fans.
Probably, but there's not much info out yet so it's rather difficult to comment on exploitability.
What will really be interesting to see is if this is exploitable via PCIe for local privilege escalation on consumer processors with vPro.
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?
The ME is used for the WoL and EEE features of the Intel NICs.
(EEE is Intel's energy efficient ethernet, allowing it to keep TCP sockets open even if the main processor is asleep).
Additionally, the ME builds its own network connections.
It's also why I stopped using any and all Intel NICs, they ended up resetting every few seconds if the ME was partially disabled.
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.
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?
I thought we were better.
https://ark.intel.com/Search/FeatureFilter?productType=proce...
If you load firmware from userspace you can probably just put it in the directory the firmware helper searches.
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.
Then look for the MEI controller: # lspci | grep "MEI"
I have a CPU without vPro, but a chipset that supports MEI.
But then, I bought the best CPU available without vPro.
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.
Both "# modprobe -nr mei" and "# modprobe -nr mei_me" report that the module isn't found.
Enabling it is tremendously difficult though AFAIK.
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.
That's a lot of computers worldwide.
Remote access to DMA capability is just batshit insanity.
It's still an OS, it's just not on the hard drive.
The real issue is that we don't have the source code for it and only the OEM can patch security vulnerabilities -- or not.
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.
There's a reason you want to keep the amount of softwares installed on a critical system, other than performance.
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).
http://invisiblethingslab.com/resources/bh09usa/Ring%20-3%20...
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.
> 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.
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.
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.
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.
They should have just expanded the address space in v6 (5?) I reckon (and maybe any warts from history that needed cleaning up).
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 ¯\_(ツ)_/¯.
Nowhere was it suggested that NAT was part of the security strategy... which you are right, is a very bad idea.
If that's the case, this might really become huge.
[1] http://ark.intel.com/Search/FeatureFilter?productType=proces...
http://ark.intel.com/Search/FeatureFilter?productType=proces...
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.
It’s quite an extensive list, and definitely not "only 2"
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.
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.
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.
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.
I can’t. My BIOS has no option for AMT.
But AMT is running, it’s exposed on the specified port via HTTP.
And this is on a consumer PC, with an i7-6700.
https://news.ycombinator.com/item?id=13056997
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.
[1] https://communities.intel.com/docs/DOC-5693
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.
Here is a wikipedia article on AMT:
https://en.wikipedia.org/wiki/Intel_AMT_versions
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.
Forgot the link: https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...
It would be really nice if Intel would categorically state which Xeon line products are and are not affected.
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.
AMT is run in the management engine. "The Intel AMT functionality is contained in the ME firmware (Manageability Engine Firmware)."
So, yes, it's the ME that was exploited. AMT is just an app for the ME.
How does Intel define an Intel-based consumer PC?
Nice list here:
http://www.thinkwiki.org/wiki/Intel_Active_Management_Techno...
We had a little subthread a few hours ago where you still claimed most consumer and server systems would be unaffected.
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.
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.
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.
In Windows, you can see your CPU model under "System", label "Processor". (Shortcut key "Windows-Pause".)
http://ark.intel.com/
Specifically, the string you want to `grep` for is "machdep\.cpu\.brand_string".
It doesn't seem like you have the HTTPS Everywhere extension enabled, here's the correct link: https://ark.intel.com/
https://virustotal.com/en/file/6754f92215f23a34aa4d34df6194b...
If an intentional backdoor is homicide, and a simple software mistake is manslaughter, this is somewhere around negligent homicide.
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.
Some vendors give you a lot a details, some are very obscure.
There is a need for a "standard" Security Advisory, on the same base that there is a "standard" emerging from Responsible Disclosure.
* Easy, unambiguous way of determining whether you're affected
* What risks are for each condition (have an AMT ready CPU, have AMT enabled, etc)
* Which patches fix which risks
And more. This will require some thought, and hopefully some UX people.
[1] https://github.com/open-power/docs/blob/master/README.md
[2] https://github.com/openbmc/openbmc/wiki
I don't know what this vulnerability is or how it is exploited and I barely know what systems of mine might be affected by it.
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.
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.
I expect to see some lock down in the next years.
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.
EDIT: If you want more info:
https://news.ycombinator.com/item?id=14242213
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).
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.
https://semiaccurate.com/2017/05/01/remote-security-exploit-...
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.
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.
My Intel network card would not work at all with AMT disabled. It simply refused to work, resetting every few seconds.
I ended up simply using an old Realtek network card, but that’s no long-term solution either.
to see if you have LMS running, which apparently is required to remotely exploit it. PDF with details here: https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20...