Red alert! Intel patches remote execution hole that's been hidden in chips since 2010 For the past seven years, millions of Intel chips have harbored a security flaw that can be potentially exploited to remotely control and infect systems with spyware. Specifically, the bug is in Intel's Active Management Technology (AMT), Standard Manageability (ISM) and Small Business Technology (SBT) firmware versions 6 to …
Every time my Lenovo ThinkPad boots up it complains it cannot find a driver for the "PCI Simple Communication Controller." That is because that AMT driver is not on my computer. I made sure it was not. And IME is also disabled in the UEFI control panel (although I suspect there is a back door around that). So what's all this "doesn't affect consumers" thing? Is it possible to install Windows without installing drivers for the IME chip?
Or maybe they are talking about my Netbook, or Chromebook, or God knows what-all, as a "consumer device."
"So is it in HP machines? Dell machines? There are a lot of those in "consumer" hands, too. "
In short, yes.
I help look after a small handful (<10) of recycled HPQ business-class PCs (some laptops, some SFF or mintower desktops). vPro/AMT capabilities are in about half of them (one obvious hint on some is the vPro mention on the Intel Inside sticker).
For years I've been reading suggestions from concerned others (and denials from Intel employees/fanbois) that those capabilities are going to be exploited one day. Search el Reg for comments on vPro and AMT and read what well-informed folks have been saying here, let alone elsewhere.
That day has been here for a while, and now it's gone public.
"It really would helpful for Intel to be a bit more specific about who is affected, but I suspect that it is not in their interests to be honest about this vulnerability..."
You might possibly think so. I couldn't possibly comment.
Workaround?
On one of the vPro-enabled desktops in the local collection, the motherboard (ie vPro) NIC wouldn't work under Windows, although it worked fine under Linux (Suse). So we ignored the vPro NIC, and put a 2nd NIC in and used that instead, to keep the Windows people happy This might be a reasonable short term option for some others who want low cost mitigation of some aspects of this latest group of vulnerabilities. Or it might not. YMMV. Just sayin'.
"The IBM/Lenovo Thinkpad line has always been oriented towards business users."
As Jim Mitchell pointed out in his reply, the ThinkPad *line* is orientated to business users. The AMT/vPro feature is definitely in some HP and Dell lines, but not all of them. For example, a Dell Latitude line unit has the feature as an option, but an Inspiron line unit doesn't. I'm not familiar with HP lines to know which ones have it as an option.
The vulnerability is not in the OS, hence Intel is issuing fixes and not Microsoft. Once Intel delivers the fix, you have to hope the OEM of your PC or motherboard bothers to issue a BIOS update for it, otherwise you'll remain vulnerable.
The good news is that according to Charlie at SemiAccurate, consumer PCs are only vulnerable to attack from the local network and not from remote attack like business PCs with the management engine enabled.
'The vulnerability is not in the OS'
Do you think this was no accident. Who would want a backdoor into all Intel hardware. As for AMT, I've seen on certain corporate 'secured' devices, once AMT is triggered and it detects you've removed the monitoring app from Windows, it downloads and executes a binary blob from an unsecured embedded URL. A poisoned local DNS server could bypass the security. In this case more security is less security :)
I have an ASRock Intel based motherboard and the BIOS has remote hardware management features which run independent of the OS. I did not pay much attention to them but switched them off and noted that this was a security hole waiting to be exploited. Last time Intel did something like this it was the PIII exposing it's unique ID.
With security they say that once you lay hands on the hardware you can break the security. Well laying the hardware out on the network you don't even need hands on the hardware.
Absolutely correct. This affects ALL Intel CPUs shipped over the last decade. While Intel's remote management software may not be installed by consumer vendors (Dell, Lenovo, etc) by default, the flaw discovered in their chips can still be exploited locally (which is how most consumer malware actually works). See this article (https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/) by Charlie Demerjian for more. Consumers should very definitely be on guard regarding this exploit, and look for a patch from their machine's vendor. If the machine was built from parts, they should go through the remediation steps in this Intel document, https://downloadcenter.intel.com/download/26754, and look for patches from their motherboard vendor.
What if this is intentional? Maybe there's a reason why China/Russia/France etc. is developing their own processor or going the ARM route. (AC obviously.)
https://hardenedlinux.github.io/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F
https://www.youtube.com/watch?v=rcwngbUrZNg
It probably is intentional, but you'll never prove it until there is another Snowden. It is not a surprise Intel dropped the ball by not hiding it better. They have been tinkering with baked in back doors for over a decade along with DRM, so they have a lot of older designs that need to be revisted and debugged. Pioneers always leave a rough trail.
It was a half-baked idea to begin with, as we all pointed out back in the day. Thankfully, it's only vulnerable remotely if it's provisioned.
Well ... today it has to be provisioned. Next week? Who knows ... There is a reason that my firewalls run BSD on aging hardware ;-)
"These are the same people who said the the F00F bug would only affect scientific computation users."
'The x87 FPU specs say that FSIN and FCOS can compute any angle in the range \\pm 2^63, which is roughly \\pm 1E18. My tests showed that even for smaller arguments, say in the order of 1E10, they produce results that are correct only for the first 10 digits and the rest are all wrong.' ref
'The products described may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.'
Doesn't need a firewall rule. The exploit exists on the bare metal. The cpu can talk - and more importantly listen - to the network interface without the OS getting involved. This thing exists at a hardware layer effectively putting it on the other side of your firewall.
It does not need firewall exception but you can neuter it by disconnecting main/built in NIC and using an add-on NIC instead. System drivers are needed for higher functions (beyond just powering it on etc). Consumer equipment does not support it (as it's a premium feature and comes with price tag) but since 2nd-ary market is full of preowned corporate stuff, I bet that the risk is not limited to enterprise. Funny thing is that the feature is expensive to get, expensive to maintain and rarely used but since it's enabled by default on supported hardware the gaping security hole is always on.
For my (desktop) intel CPUs, running linux, I already have firmware updates which get applied by the kernel on each boot. I assume there will be new updates to fix these latest known issues ?
Strangely, only my oldest still-occasionally-running AMD CPU has ever got a firmware update - but that might be because I have bought AMDs later in their life, and the mobo manufacturers have already applied updates. Or just that intel has had to fix the fixes.
Can probably be interpreted for other systems including windows too, if you have the expertise to read-across:
I only run computing hardware on processors I designed myself!
Not good enough, unless you run your own fab line to make them. There is plenty of research on hardware level back doors, some of which take only a few gates.
If your fab lines are controlled by Intel chips, then you're down the rabbit hole and into the realm of Ken Thompson's Trusting Trust paper.
/* sc.c */
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <arpa/inet.h>
static void print_recvbuf(const unsigned char *buf, size_t size)
{
size_t i;
for (i = 0; i < size; ++i)
{
(void) fprintf(stderr, "0x%x ", (unsigned int) buf[i]);
if ((i % 10) == 0)
(void) fprintf(stderr, "\n");
}
}
int main(int argc, char *argv[])
{
int sockfd = 0, n = 0, port = 0;
unsigned char recvbuf[1024];
struct sockaddr_in serv_addr;
if (argc != 3)
{
(void) fprintf(stderr,
"Usage: %s <ip-address> <port>\n", argv[0]);
return 1;
}
port = atoi(argv[2]);
if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
(void) fprintf(stderr,
"error: socket(3) could not create socket!\n");
return 1;
}
(void) memset(&serv_addr, 0, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(port);
if (inet_pton(AF_INET, argv[1], &serv_addr.sin_addr) <= 0)
{
(void) fprintf(stderr, "error: inet_pton(3) error!\n");
return 1;
}
if (connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0)
{
(void) fprintf(stderr, "error: connect(3) failed!\n");
return 1;
}
(void) memset(recvbuf, 0, sizeof(recvbuf));
while ((n = read(sockfd, recvbuf, sizeof(recvbuf)-1)) > 0)
print_recvbuf(recvbuf, n);
if (n < 0)
(void) fprintf(stderr, "error: read(2) error!\n");
close(sockfd);
return 0;
}
%> gcc --version
gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
%> gcc -g -O2 -std=c99 -Wall -Wextra sc.c -o sc
%> ./sc 127.0.0.1 16992
error: connect(3) failed!
%> ./sc 127.0.0.1 22
0x53
0x53 0x48 0x2d 0x32 0x2e 0x30 0x2d 0x4f 0x70 0x65
0x6e 0x53 0x53 0x48 0x5f 0x37 0x2e 0x32 0xd 0xa
^C
%> uname -a
Linux xxxxxxxxx.xxxxxxxxx.xxx 4.7.10-100.fc23.x86_64 #1 SMP Wed Oct 26 23:29:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
%> cat /proc/cpuinfo
[ ... ]
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz
stepping : 5
microcode : 0x7
cpu MHz : 931.000
cache size : 6144 KB
[ ... ]
It looks like some additional software is needed for this vulnerability to be enabled, because no-one seems to be listening on port 16992 on an - admittedly old-ish - Corei7.
That test looks flawed to me.
AMT sits between the physical ethernet controller and the os.
127.0.0.1 only represents the visual lo loop back device and therefore goes nowhere near the network hardware. Even doing that to the ip address assigned to your nic wouldn't work as the kernel would know that it doesn't need to send across the network.
Try it from another host on your network towards your i7 and you will get more accurate results.
> That test looks flawed to me.
> Try it from another host on your network towards your i7 [ ... ]
Yaaaa.
%> ./sc 192.168.0.2 16992
error: connect(3) failed!
%> ifconfig -a
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.6 netmask 255.255.255.0 broadcast 192.168.0.255
ether 10:bf:48:26:8b:f1 txqueuelen 1000 (Ethernet)
RX packets 74 bytes 16010 (15.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 108 bytes 9488 (9.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
Seriously?
No need for all this. If AMT is provisioned it will set up a web server that listens on port 16992 or 16993, so either a browser or telnet will do to see if it's listening.
Bear in mind that it will often have an IP address (IPv4, IPv6 or both, allocated statically or through DHCP) *different* from the OS that's running on the machine. In fact it's considered best practice for AMT to have a different IP address.
For sysadmins who've lost the plot and need to do an audit, it would probably be best to scan the entire subnet to see if anything is listening on 16992 or 16993.
I hope this issue gets widely publicised. It could be one of the major IT security failures we've seen to date, and we all know that most systems won't be patched but will remain in service for many years to come. In my wildest fantasies I'd love the industry to use this as impetus to totally reassess how buggy / flawed firmware is dealt with after the manufacturers have walked away.
> In my wildest fantasies I'd love the industry to use this as impetus to totally reassess how buggy / flawed firmware is dealt with after the manufacturers have walked away.
Well, mates ... the solution is dead simple ... firmware ? make it open source. Let us freetards fix what needs fixin', cheaper, yes, safer, yes, why do they not do it ? Because they are dumb fuck!
https://www.youtube.com/watch?v=bw58LZTuZjA
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
