back to article 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 …

  1. Dr Trevor Marshall

    It IS in consumer PCs

    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."

    1. Jim Mitchell

      Re: It IS in consumer PCs

      The IBM/Lenovo Thinkpad line has always been oriented towards business users.

      1. Dr Trevor Marshall

        Re: It IS in consumer PCs

        So is it in HP machines? Dell machines? There are a lot of those in "consumer" hands, too. 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...

        1. Anonymous Coward
          Anonymous Coward

          Re: It IS in consumer PCs (possibly with partial workaround??)

          "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'.

        2. PuterPuterPuter

          Re: It IS in consumer PCs

          "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.

    2. Anonymous Coward
      Anonymous Coward

      Removing the driver doesn't affect the vulnerability

      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.

      1. Anonymous Coward
        Terminator

        Re: Removing the driver doesn't affect the vulnerability

        '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 :)

      2. toughluck

        Re: Removing the driver doesn't affect the vulnerability

        The good news is that according to Charlie at SemiAccurate, consumer PCs are only vulnerable to attack from the local network

        Yeah, like public WiFi used by millions around the world.

        1. Anonymous Coward
          Anonymous Coward

          Re: Removing the driver doesn't affect the vulnerability

          Properly configured (by default if you are using DD-WRT or OpenWRT) public wifi does not permit clients on a guest segment to talk to each other.

          1. Ken Hagan Gold badge

            Re: Removing the driver doesn't affect the vulnerability

            @DougS: Properly configured, Intel don't leave back-doors in their CPUs. Clearly we don't live in a properly configured world.

    3. Wayland

      Re: It IS in consumer PCs

      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.

      1. Anonymous Coward
        Anonymous Coward

        Re: It IS in consumer PCs

        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.

  2. John Smith 19 Gold badge
    FAIL

    Don't you wish Intel would stop being so "helpful"

    This stuff cannot be over ridden. It's baked into the chip.

    So it looks like Intel is another company that does not do software very well.

    1. Anonymous Coward
      Anonymous Coward

      Re: Don't you wish Intel would stop being so "helpful"

      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

      1. Anonymous Coward
        Anonymous Coward

        Re: Don't you wish Intel would stop being so "helpful"

        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.

    2. streaky

      Re: Don't you wish Intel would stop being so "helpful"

      This stuff cannot be over ridden. It's baked into the chip.

      Yeah but it's not exploitable unless you enable and configure a bunch of stuff, from remote anyway.

  3. jake Silver badge

    It was only a matter of time.

    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 ;-)

    1. streaky

      Re: It was only a matter of time.

      "There is a reason that my firewalls run BSD on aging hardware"

      Hope that isn't pfsense. *cough*.

      Seriously it's a useful tool in principle, it's just badly implemented (like all the alternatives) and DMA shouldn't be anywhere near it.

  4. Anonymous Coward
    Anonymous Coward

    Thankfully I'm a tight arse when when it comes to spending on motherboards.

  5. doke

    Intel's normal reaction is denial

    These are the same people who said the the F00F bug would only affect scientific computation users.

    1. Anonymous Coward
      Terminator

      Intel 2^63™ not equal to 2^63 ..

      "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.'

  6. rh16181618190224

    Domestic HP laptop user here

    The service was present and running, but does not appear to be listening - using the Intel document as guidance. Also I cannot see a windows firewall rule that would allow an inbound connection.

    1. theOtherJT Silver badge

      Re: Domestic HP laptop user here

      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.

      1. joed

        Re: Domestic HP laptop user here

        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.

  7. Anonymous Coward
    Anonymous Coward

    I assume Intel has told the world about this now because they are afraid it will come out in the next leak of NSA attack documents.

    By telling us about this one they hope we don't go looking for the other NSA back-doors into computer systems that are baked into the CPUs.

    1. Anonymous Coward
      Anonymous Coward

      In a slightly different light

      Still feel as negatively disposed towards Wikileaks and Julian Assange now?

  8. a_yank_lurker

    Link Issue

    Chpizilla discussed Bloat and ignored other OSes in their description. Since it is hardware and other OSes run on their silicon they should put out instructions for the others as well. Sleazy scum.

    1. Anthropornis
      Linux

      Re: Link Issue

      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.

  9. Gene Cash Silver badge

    Richard Stallman must be laughing his ass off right now. This is exactly the sort of thing he preaches about.

  10. Anonymous Coward
    Anonymous Coward

    Holy shucking fit

    That's almost a decade of being wide open. Good job intel, well played.

    I'm glad I'm an AMD customer.

    1. Voland's right hand Silver badge

      Re: Holy shucking fit

      I had my hair rise on the back of my neck the moment I read the description of the feature back in ~ 2005-2006 when it first came out. My first thought was: "this is perfect for a backdoor, how can I disable it". Looks like I was right.

    2. Anonymous Coward
      Anonymous Coward

      Re: Holy shucking fit

      "I'm glad I'm an AMD customer".

      Starting today, so am I.

    3. Down not across

      Re: Holy shucking fit

      I'm glad I'm an AMD customer.

      ...until a flaw in PSP is published.

      1. jake Silver badge

        Re: Holy shucking fit

        "Until the flaw^Wbackdoor(s) in PSP is published."FTFY

  11. Nick Kew

    A linux take on this

    Can probably be interpreted for other systems including windows too, if you have the expertise to read-across:

    http://mjg59.dreamwidth.org/48429.html

  12. Anonymous Coward
    Linux

    Vuln reported over five years ago and totally ignored by Intel

    "SemiAccurate has known about this vulnerability for literally years now, it came up in research we were doing on hardware backdoors over five years ago." link

  13. Schultz
    Mushroom

    Does this mean ...

    the we discovered the skynet command and control hardware in time?

  14. Anonymous Coward
    Anonymous Coward

    Rombi Rombi Runescape

    When a vendor prevents you looking under the hood then what you get is what is good for them not you.

  15. Anonymous Coward
    Anonymous Coward

    See!

    This is why you penguinistas out there are all fools! Sure, convince yourselves that you're safe because you compiled your own kernel. I only run computing hardware on processors I designed myself!

    1. Richard 12 Silver badge

      Re: See!

      Very funny.

      The penguins are the ones who will probably save us, as they are the people with the expertise and the time to patch the unsupported hardware.

      This is a time when we learn a lot about the various high profile vendors. How far back will they publish patches?

    2. Arthur the cat Silver badge

      Re: See!

      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.

      1. 404

        Re: See!

        Fab? What's that?

        I use breadboards.... my x86 .5Mhz bread loaf is the size of a small car... working on the 1.5Mhz upgrade now if I can source another bundle of old telco copper......

        *why is there not a finger-in-mouth woob_woob_woob crazy eyes icon?

        1. Anonymous Coward
          Joke

          Re: See!

          Is that your own copper you have mined yourself?

          If not, you may not be using the copper atoms in the correct orientation, allowing it to send info back up the copper...

          1. jake Silver badge

            Re: See!

            It's OK, he's using MonsterCable(tm)! It's MAGIC!!!!11!!one!!!eleven!!!11!!!!

    3. Wayland

      Re: See!

      Make your own CPU? Well you should see LinusTechTips attempt to make a CPU cooler. It looks like something out of the FlintStones.

  16. Anonymous Coward
    Linux

    PANIC!!!!!!!!!! :-)

    /* 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.

    1. djack

      Re: PANIC!!!!!!!!!! :-)

      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.

      1. Anonymous Coward
        Devil

        Re: PANIC!!!!!!!!!! :-)

        > 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?

        1. Not Terry Wogan

          Re: PANIC!!!!!!!!!! :-)

          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.

          1. Hans 1

            Re: PANIC!!!!!!!!!! :-)

            > 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

            1. Anonymous Coward
              Anonymous Coward

              Re: PANIC!!!!!!!!!! :-)

              Sane, simple first steps

              Install nmap.

              run:

              nmap -p 16992-16995,623,664 192.168.1.0/24 (or your network range in CIDR format)

              Look for opens.

              As I understand it, closed is fine, Windows boxes with the firewall on will report 'filtered' on the OS side most likely, and as I understand it, should be fine. As long as it's not wide open, it's not a problem. (obviously context on whether it's on a localnet or on the internet is important - use yer noggin on that)

              if you see opens, investigate carefully. I have port 623 open on one server, but the intel manageability stuff isn't installed/running so should be fine (the other ports aren't open, either).

              Info borrowed from the SANS post here:

              https://isc.sans.edu/forums/diary/Do+you+have+Intel+AMT+Then+you+have+a+problem+today+Intel+Active+Management+Technology+INTELSA00075/22364/

              1. Anonymous Coward
                Anonymous Coward

                Re: PANIC!!!!!!!!!! :-)

                Just a little update - it's the AC with the nmap command above - the one server I had port 623 open on was a vendor BMC, which doesn't appear to be affected.

                Certainly, the Intel discovery tool (listed in the article; handily, it's a Windows box) doesn't recognise it as being one of the affected platforms, so I think I'm OK on that front.

                Slightly panicky morning to say the least.

    2. Wayland

      Re: PANIC!!!!!!!!!! :-)

      You clearly don't get it.

      It's the hardware itself that's reading the port. If it uses UDP messages then there need be no acknowledge, totally stealth.

      What's worse is that they could easily make the hardware scan for an escape code in any data stream to activate. Something that nobody would ever have in a data stream like "The woods are lovely dark and deep, but I have promises to keep, and miles to go before I sleep"

      1. Anonymous Coward
        Mushroom

        Re: PANIC!!!!!!!!!! :-)

        > You clearly don't get it.

        Oh, and you do. Riiiight.

        > It's the hardware itself that's reading the port.

        No, Einstein, it's not the "hardware that's reading the port" or any other such nonsense.

        Had you - and any of your like-minded commentards - ever bothered to read the explanation at SANS, you would have discovered that this AMT software - which exists only for Windows, apparently - installs and runs a http server that listens on one of the following ports: 16992., 16993, 16994, 16995, 623 or 624. This is discoverable by running a simple curl http request to one these ports, regardless of whether or not the connection is made to the loopback interface or to an IP interface.

        Yes, you read that right: AMT software starts up a http server on your box. Not even https, just plain http.

        So stop posting pseudo-savant explanations about the hardware scanning for data streams and some other such clueless bullshit about networking.

        Here's the thing: if you decided that installing any piece of software that allows for remote management of your computer was a good idea, you only have yourself to blame for the consequences. Here's a plain English explanation of what remote management really means: remote and arbitrary code execution with escalated privileges.

        Now you know.

        1. Chemist

          Re: PANIC!!!!!!!!!! :-)

          "which exists only for Windows, apparently "

          Not sure about that - see the How-To

          https://linux.die.net/man/7/amt-howto which in any case provides more info. about AMT

          See also https://linux.die.net/man/1/amtterm (amtterm provides access to the serial-over-lan port of Intel AMT managed machines.)

          https://linux.die.net/man/1/amttool (amttool is a perl script which speaks SOAP to Intel AMT managed machines. It can query informations about the machine in question and also send some commands for basic remote control. )

          Although my i7 laptop reports using lspci :

          00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) it doesn't seem to be exposed on a port, possibly I need to plug an ethernet cable in. There are definitely kernel modules running that are related (mei_me & mei) and an entry in /sys/bus/mei and /dev/mei

          (Prominent usage of the Intel ME Interface is to communicate with Intel(R) Active Management Technology (Intel AMT) implemented in firmware running on the ...)

          https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt.

          1. Anonymous Coward
            Anonymous Coward

            Re: PANIC!!!!!!!!!! :-)

            > 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)

            Neither of my Linux laptops seem to have it:

            %> lspci | egrep 'Communication'

            %>

            So either it's disabled - I may have disabled it in the BIOS and I can't remember if I did that or not right now, or my i7's are too old.

            And Intel emphatically states that consumer-level chipsets are not vulnerable (see the link at SANS). So that could be true too.

            1. dlc.usa

              Re: PANIC!!!!!!!!!! :-)

              "Neither of my Linux laptops seem to have it"

              See http://cateee.net/lkddb/web-lkddb/INTEL_MEI_ME.html for a list of PCI IDs.

          2. Anonymous Coward
            Anonymous Coward

            Re: PANIC!!!!!!!!!! :-)

            Same AC - good shout Chemist, honestly, it never struck my mind to look other than on the intel support page. More fool me, I suppose.

            Simple things first (again)

  17. Chemist

    SANS

    Have a entry for this with some tests

    https://isc.sans.edu/

  18. John Smith 19 Gold badge
    FAIL

    " It freaks out privacy and security conscious people: "

    As it bloody well should

    A remotely accessible sub processor inside the Intel chip.

    Running poorly vetted code you cannot change.

    With a "bug" that allows password free access to it.

    Congratulations. Intel has given IoT level security to every desktop that runs it.

    Yes this smells of collusion with a TLA. You have to wonder what they are running on the desktops inside Fort Meade.

  19. Anonymous Coward
    Anonymous Coward

    So is there any reason to enable AMT on a consumer pc and does disabling it in bios fix the security hole ?

    1. Sandtitz Silver badge

      "So is there any reason to enable AMT on a consumer pc and does disabling it in bios fix the security hole ?"

      No reason unless you'd need to remotely use that consumer pc without 3rd party or even OS built-on remote connection software.. With AMT you can remotely change BIOS settings, install an operating system etc. - anything you can do locally with your mouse and kb can be done via AMT (depending on the implementation.) The remote screen mechanism uses standard VNC protocol and the remote user can thus use any VNC client with it.

      You can fix this security snafu be either disabling it in BIOS or updating the firmware if your vendor provides a fix.

      1. Ken Hagan Gold badge

        "With AMT you can remotely change BIOS settings, install an operating system etc."

        These days, you can do most of that by running a hypervisor on the bare metal and a single OS guest on top. Intel's VT-x features ought to make that reasonably performant. Perhaps AMT is an idea whose time has now past.

      2. This post has been deleted by its author

  20. JimmyPage Silver badge
    Linux

    So, Intel, where is the Linux version of the tool ????

    ****ing morons.

    1. Anonymous Coward
      Anonymous Coward

      cat /proc/cpuinfo and look it up on the table below.

      https://ark.intel.com/Search/FeatureFilter?productType=processors&VProTechnology=true

  21. naive

    The Patriot Act is a disease

    Baked in back doors in server grade CPU's with a market share of over 95% ?... sounds like the perfect April fools joke.

    One day Europe should wake up, to take a stance against usage of IT Tech produced by companies who operate under US law.

    But probably, too many EU politicians have been bought into this spy game as well, effective rulings to end this spy-fest will probably not be rushed out.

    The naivety with which organizations move workloads to MS Azure, use external Symantec email relays for "scanning" and other "cloud services" of US based companies is sickening.

    Be happy, don't worry, tomorrow we have all forgotten this.

    1. Anonymous Coward
      Anonymous Coward

      Re: The Patriot Act is a disease

      "Baked in back doors in server grade CPU's with a market share of over 95% ?"

      Don't forget it's also in many business-class desktops and laptops too.

      It's even baked into many of the chips and systems that don't advertise it, with the value-added functionality disabled at the time the chips are tested and classified. Well, allegedly disabled.

      "Be happy, don't worry, tomorrow we have all forgotten this."

      Many people might have. Not everyone. I bought my first vPro/AMT system several years ago (an HPQ business-class desktop, a DC7700), with a view to looking into just what it was all about (and how secure it might be). Never happened, other things got in the way. And a few weeks back I bought a new-to-me business-class laptop which also comes with these features.

      Hopefully now others will have a bit of fun with these features.

  22. Diginerd

    Active Network Defense for this...

    Worked on this threat a few years back.

    If you've got Cisco switches and don't use AMT it's pretty easy to defend against the "off box" vector (and other similar nasties) by using a VACL.

    That way traffic is blocked before it can traverse to another port in the same VLAN. Applying a regular router/firewall packet filter ACL won't prevent an attacker pivoting through a compromised host on your LAN (hint look at your edge devices too;).

    On the other hand switch based VACLs will drop attack traffic in hardware (no performance impact).

    <rant>

    For all the head in the sand folks - how secure are your printers, edge devices (cheesy botnet infected junk?) and security cameras? Are you sure you know EVERY device on EVERY port at ALL times?

    Hopefully this gets more publiscised and the PHBs start to realize that checking off "PCs have a lol OS patches" and "Firewalls are audited" hasn't been a comprehensive security strategy for decades.

    </rant>

  23. Robert Carnegie Silver badge

    Presumably,

    Any desktop vulnerability that allows arbitrary code execution as the local user, can use this facility to escalate to the access level of, uh, Intel themselves?

    Or maybe it can be invoked straight from Javascript?

    1. Diginerd

      Re: Presumably,

      Yes.

      See Atwood's law.

    2. Anonymous Coward
      Anonymous Coward

      Re: Presumably,

      Yes, it is locally exploitable at the ethernet port. It'd take me a day to gin up a portable to do that once I have more details on the exploit. [I'm not going out of my way for details as I've dodged a major bullet here with respect to this.] Couple of days, if I wanted something unobtrusive. Parts isn't something I lack around my place ;-).

      Exploitable from Javascript? Not enough knowledge here on that as you'd need to target another box on the network from any given PC. I avoid Javascript almost as much as I do Java. [And no, they aren't related. I know that. I simply loathe both.]

  24. Anonymous Coward
    Anonymous Coward

    What does this vulnerability actually enable?

    There's lots of talk and lots of comment but very little hard info I've found this morning on what AMT/vPro/etc does (beyond handwaving such as "manageability") and beyond software-security-culture terms such as "privilege escalation" (and "remote code execution" and the rest).

    Where can I go for clear hard info on what's been vulnerable and what's now allegedly fixed?

    This isn't a software security vulnerability. It's not really amenable to the usual classifications, the usual terminology is *not* (imo) helpful here.

    Based on my limited understanding of vPro etc here's my understanding of some of the stuff that's been achievable for years despite not having the allegedly required authorisation:

    * Hardware-level keyboard/video/mouse redirect, no OS or application necessary on the target system, the 'manager' can remotely control and monitor the 'controlled' system's keyboard video and mouse

    * Hardware-level storage redirect, no OS or application necessary on the target system, the 'manager' can have the 'target' access remote storage as though it was local to the target.

    Actually, is that enough to be going on with?

    You can probably see why it'd be handy for the typical IT department PC jockey doing remote installs or remote support (this is *not* just for servers - again, this is *not* just for servers). It's supposed to be protected by various layers of security, which as the world now knows, isn't trustworthy. Gosh, who'd have thought that.

    You can probably see why others outside the IT department might be interested too.

    Another question I'd be interested in: both CPQ/HP and Dell servers have had their own equivalents of the above functionality, for years, even before vPro/AMT (for CPQ it's the iLO or integrated Lights Out facility, can't remember what the Dell variant is called). Do these systems also have the newly publicised vulnerabilities?

    1. Diginerd

      Re: What does this vulnerability actually enable?

      Look up "impi" for related server carnage.

      Lots of work already done on this general topic.

      Various KEYWORDs and info about capabilities public ally available too.

      TL;DR the rabbit hole is very deep and it's going to be a problem for a long time.

      1. Anonymous Coward
        Anonymous Coward

        Re: What does this vulnerability actually enable?

        "Look up "impi" for related server carnage."

        Is that "impi" or "IPMI" ?

        Let's assume for now that you meant IPMI.

        In which case further reading might include:

        https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface

        https://www.thomas-krenn.com/en/wiki/IPMI_Basics

        http://www.itworld.com/article/2708437/security/ipmi--the-most-dangerous-protocol-you-ve-never-heard-of.html

        IPMI and AMT/vPro/etc are very closely connected, with common parentage.

        While I'm here again: something I meant to mention in my earlier "what can you do" post: if a machine is "switched off" but still has mains power, AMT/vPro/IPMI etc provide a standardised way of powering it up remotely. And (again) **not just on servers**, also business-class desktops and laptops and...

        1. Diginerd

          Re: What does this vulnerability actually enable?

          Yes. *Blush*

          /muttersdarkly about stupid dyslexiz.

          Ty for catch

    2. Nick Ryan Silver badge

      Re: What does this vulnerability actually enable?

      Another question I'd be interested in: both CPQ/HP and Dell servers have had their own equivalents of the above functionality, for years, even before vPro/AMT (for CPQ it's the iLO or integrated Lights Out facility, can't remember what the Dell variant is called). Do these systems also have the newly publicised vulnerabilities?

      No, they have their own vulnerabilities. A good pen scan will show these buggers running antiquated versions of shared libraries, are know to have hard coded passwords and many other horrors. On the other hand, they are very, very useful.

      1. Anonymous Coward
        Anonymous Coward

        Re: they are very very useful (iLO server management)

        "A good pen scan will show these buggers running antiquated versions of shared libraries, are know to have hard coded passwords and many other horrors. On the other hand, they are very, very useful."

        OK, but is it the customers finding them useful, or, well, y'know, like, Orwell.

        We have always been at war with Eastasia.

      2. naive

        Re: What does this vulnerability actually enable?

        Maybe this sheds some light on this: https://libreboot.org/faq.html

        Every computer equipped with Intel or AMD chips, consists of two computers. The visible one can be used to run Windows or Linux end user operating system. The invisible second computer can access every bit of information residing on disks and memory, and transfer it to somewhere else using the networking capabilities of the OS.

        Combine this with the secretive and undocumented nature of this second computer, it is an excellent platform to enable targeted attacks on individuals and organizations. Coding for spyware can be installed in encrypted form, and no one will ever notice their trusty 1U server happily humming in the highly secured data center is busy sending all kinds of stuff to a remote server using port 80.

        1. Anonymous Coward
          Anonymous Coward

          Re: What does this vulnerability actually enable?

          "Maybe this sheds some light on this: https://libreboot.org/faq.html"

          Oh wow. Thank you so much, that document does (for me at least) help clarify what is actually made possible by this collection of vulnerabilities and 'defective by design' hardware and software.

          One very basic clarification which may help others who are unaware of libreboot (as I was until a few minutes ago):

          It's not lib reboot (which I initially assumed it was).

          It's libre boot.

          Though in a way, both are applicable.

          Thank you very much indeed to the people behind libreboot.

          "[...] no one will ever notice their trusty 1U server happily humming in the highly secured data center"

          Reminder: AMT, vPro, etc capabilities are also found in many business-class laptops and desktops which aren't in the data centre but may still contain highly sensitive materials or perform highly sensitive functions.

          Trying to confirm whether the exact same vulnerabilities apply to non-server systems seems difficult, but given that software and hardware tends not to be entirely bug-free, it might be safest to assume that there might well be *equivalent* vulnerabilites discovered in due course.

          Oh dear.

  25. Gnosis_Carmot

    Vault7

    Wonder if this was something exposed with Vault7.

  26. WebspaceMatt

    For anyone who has bothered to download the Intel diagnostic tool, it has to be run from command line and it is particular. The following command (executed from within the directory containing the executable) worked for me:

    SCSDiscovery.exe /Output Console SystemDiscovery /NoRegistry

    This will generate an XML file in the same directory containing the diagnostic output. It's fairly easy to digest even if you don't have an XML reader.

  27. Destroy All Monsters Silver badge
    Mushroom

    Small Business Advantage? Very Small Indeed.Minidick levels of small.

    There are more ® signs in these bullshit Intel arse-covering documents than there is information.

    If this is true:

    First a little bit of background. SemiAccurate has known about this vulnerability for literally years now, it came up in research we were doing on hardware backdoors over five years ago. What we found was scary on a level that literally kept us up at night. For obvious reasons we couldn’t publish what we found out but we took every opportunity to beg anyone who could even tangentially influence the right people to do something about this security problem. SemiAccurate explained the problem to literally dozens of “right people” to seemingly no avail. We also strongly hinted that it existed at every chance we had.

    Various Intel representatives over the years took my words seriously, told me I was crazy, denied that the problem could exist, and even gave SemiAccurate rather farcical technical reasons why their position wasn’t wrong. Or dangerous. In return we smiled politely, argued technically, and sometimes, usually actually, were not so polite about our viewpoint. Unfortunately it all seems to have been for naught.

    ...then we are talking Thalidomide levels of bullshit. I hope a 60 billion dollar fine for shoddy overpriced shit endangering the public is roilling down the highway soon. Uncle Sam needs those because military budgets, they are increasing. It would only be just.

  28. EveryTime

    You can't disable this vulnerability.

    You can "flip the virtual switch" to the position labeled 'Off', but that switch is only connected to the indicator light.

    We learned this long ago, with the previous iteration of Intel System Management Mode/Interrupts. An OS would lose hundreds of microseconds at a time, sometimes even missing ticks of the time-of-day clock. "Disabling" the feature would reduce the gaps to 10s of microseconds, which fixed the user-visible problems of losing time, but not the pain for OS developers trying to manage hard-real-time response.

    The same was true of the network adapters, which were obviously still receiving management frames even though they were not being passed to the OS driver.

  29. gtallan

    Apple unaffected? Really?

    "Modern Apple Macs, although they use Intel chips, do not ship with the AMT software, and are thus in the clear."

    This just doesn't sound credible to me. Apple have a special batch of Intel processors without the management engine? Or are they all just consumer-line systems which supposedly have the AMT capabilities fused off? This could use some clarification.

  30. Outernational

    Simple Mitigation Guide

    Here's a concise, plain English guide on how to follow the mitigation steps: https://mattermedia.com/blog/disabling-intel-amt/

  31. fourth of three

    SPARC core?

    "These days, the Management Engine uses a SPARC core."

    Being a sparc fan, this brought a sad smile to my face.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like