Intel Patches Remote Execution Hole That's Been Hidden In Its Chips Since 2008 (theregister.co.uk)
Chris Williams reports via The Register: Intel processor chipsets have, for roughly the past nine years, harbored a security flaw that can be exploited to remotely control and infect vulnerable systems with virtually undetectable spyware and other malicious code. Specifically, the bug is in Intel's Active Management Technology (AMT), Standard Manageability (ISM) and Small Business Technology (SBT) firmware versions 6 to 11.6. According to Chipzilla, the security hole allows "an unprivileged attacker to gain control of the manageability features provided by these products." That means hackers exploiting the flaw can silently snoop on a vulnerable machine's users, make changes to files and read them, install rootkits and other malware, and so on. This is possible across the network, or with local access. These management features have been available in various Intel chipsets for years, starting with the Nehalem Core i7 in 2008, all the way up to Kaby Lake Core parts in 2017. According to Intel today, this critical security vulnerability, labeled CVE-2017-5689, was found and reported in March by Maksim Malyutin at Embedi. To get the patch to close the hole, you'll have to pester your machine's manufacturer for a firmware update, or try the mitigations here. These updates are hoped to arrive within the next few weeks.
According to them, they've been trying to get Intel to patch this for YEARS, and apparently they never bothered to practice responsible public disclosure in order to force intels hand.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Isn't that about how log I've been griping on Slashdot about AMT?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Keep in mind that this is a security hole in a system that was always backdoored by Intel.
It's a separate CPU with its own network connection, outside the control of the main CPU, it has full access to all the system and it was put in place deliberately by Intel. It communicates using SOAP over HTTP or HTTPS.
It has been in all server and business chips FROM INTEL for years now....
It can kill a PC, it can wipe harddisks (killing encryption keys used to access encrypted disks), it can read everything, do anything, rewrite the processor software, bypass any encryption and any security.
Hardware vendors had access to this for years.
So NSA would have had access to this for years.
Russian FSB would have had access to this for years.
China would have had access to this for years.
And now every hacker has access.
When you backdoor technology you end up with bad actors putting Orange Julius in office.
* Does this affect every PC, or just people who bought special "business class" computers?
* If it affects all PCs, does "pester your machine's manufacturer for a firmware update" mean the same thing as "check your motherboard manufacturer's website for a patch," or does it imply that you're SOL if you built your own PC from parts?
* Intel's patch is Windows only. Does it affect Linux, or is Intel just being lazy?
* Should I tell my family to buy new PCs if their old PCs are out of warranty?
Why do you idiots always assume that the US would be the only country interested in spying? You think Intel is a US company? Think again.
The CTRL-p menu (after much of the booting had taken place) brought me to a AMT/ME screen where I could turn AMT off after entering a password.
The default password is "admin" which worked with my refurbished HP Xeon box. I have since changed the password.
Every single Intel CPU has this hardware. The business SKUs just have it enabled. It's still there with the same blob, likely with the same vulnerability.
If you ask them right at 12:00, they could!
How is Microsoft going to patch something happening in the hardware underneath their OS, without the OS knowing anything about it? In case you haven't played with Intel AMT or vPro, it has some pretty amazing capabilities for remote management, including being able to persist remote control sessions across OS reboots, including being able to enter BIOS / uEFI setup and make changes, as well as mount an ISO image from a network volume as a 'physical' disk and boot off of it.
How could an OS that isn't even running patch that?
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
There is remote provisioning for Intel ME / Intel vPro, but it's not the easiest thing in the world to set up, much less spoof. For example, you would need to have a certificate signed by a public provider that is specifically signed for Intel ME provisioning, and the domain on that cert needs to match the domain being offered by DHCP on the network. This ensures that a public CA has basically signed off on your ownership of that domain, and that you also own your network to a decent degree by controlling the infrastructure.
Can all of that be beaten? Probably. But at that point there's probably far easier exploits to take advantage of.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
When it *is* running, it could apply the firmware to the BIOS/UEFI system. This may require a reboot somewhere in the middle, but so be it. And then the system would be safe.
Of course, that greatly simplifies the concept since every motherboard has its own variation on BIOS/UEFI. As long as we're dreaming of ponies and rainbows, yeah, this would be nice. But I can see it being a huge headache for MS or Linux distros to manage.
And just think about the poor saps running Hackintosh systems... no way Apple is going to ship firmware for non-Apple-branded systems! :)
You'd have to turn on AMT to begin with in order for this to work.
You'd have to turn on AMT to begin with in order for this to work.
Are you absolutely positive AMT cannot be remotely activated? Given the circumstances and who might be involved in this exploit existing and/or remaining unpatched for such a long time, I wouldn't trust that clicking to un-check that AMT box disables all of it, especially if the vulnerability was deliberate.
This makes me wonder what vulnerability nastiness has remained undiscovered/unreported (intentionally baked-in?) about AMD CPUs and chipsets. You know the TLAs wouldn't ignore AMD.
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
It's funny how many critical security flaws are so devious that they allow state-actors to just walk right in, and when they're found they stick out like sore thumbs. This here is exactly why you shouldn't buy CPUs from NSA-CIA-Intel.
The affected LMS service is enabled and run at startup by default in Windows 10.
Only if you have a CPU and motherboard chipset with vPro, which very few of them do. I had a look at some of the entries on Intel's list of Skylake desktop products for the consumer-level products, but got bored trying to find which of the CPUs had vPro support. I ended up looking at the motherboard chipsets, and only the Q170 supports it. The Z170, H170, Q150, B150, and H110 chipsets do not.
The original poster's point stands, that this does not affect consumer-grade PCs. Most people can happily ignore this vulnerability.
No you are actually incorrect. It is common for the operating system to update bugs in specific firmware. For example the microcode for the CPU can either be updated by flashing the BIOS or through an OS update.
Apparently you just have to make sure the LMS service in Windows is not installed or is disabled. Or not run Windows? That's the software that passes the requests to the firmware.
Not according to this analysis:
So the firmware is intercepting the traffic before the OS gets it. Turning off the LMS service would stop the remote console, but not the ability to reboot the machine into a remote ISO. At that point, your files would be visible unless you encrypted your drive.
As for not running Windows, that won't help. Further down the page linked above, it has instructions for Linux on how to see whether you are vulnerable. It also says:
Wait a minute. This (partly intentional) flaw affects practically every Intel-based PC since 2008 and some platforms since 2006. It's true that if you have remote management disabled it appears to lead to local exploits only at first sight, but there are many reasons to believe that even with the option disabled remote exploits may become possible. ME allows the running of signed Java programs on a completely separate core, which are sent via ethernet and have full access to memory and i/o controllers, it can be used to side-channel attack disk encryption and the probability that there is a serious bug that allows for remote exploits in such a complex infrastructure is also fairly high.
I may be a shill, but you are a plain nut-job! I provided a list of non-server Skylake CPUs and motherboard chipsets along with a list of the chipset model numbers that have vPro facility. All you provided was a strongly worded and unsupported assertion. If you had wanted to prove me wrong and actually believed your own rantings then you would have gone through the entire list and counted how many do and don't support vPro. Then you could have gloated about how wrong I was. But you didn't, so I will. Of the desktop CPUs, 6 support vPro while 22 do not. And as I said before only 1 in 6 of their chipsets would actually allow the CPUs to use that feature. You are wrong.
I do wonder why would you say we shouldn't trust Intel's word on their deliberate backdoors when they have been completely upfront (and even boasted) about the remote access facility of AMT! Nothing about this latest revelation shows that Intel have lied about anything.
If you have no evidence to support your notion that every Intel chip is secretly spying on you then don't swear at people who don't share your paranoid ravings. Some of us would rather have proof before we dusted off our pitchforks. That said, I would never buy a CPU that had remote access built in simply to avoid a potential attack vector. But there is a big difference between prudence and paranoia.