Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Intel Privacy Security Hardware Technology

Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought' (arstechnica.com) 200

An anonymous reader quotes Ars Technica: A remote hijacking flaw that lurked in Intel chips for seven years was more severe than many people imagined, because it allowed hackers to remotely gain administrative control over huge fleets of computers without entering a password. This is according to technical analyses published Friday... AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all...

"Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote. "We had discovered a complete bypass of the authentication scheme." A separate technical analysis from Embedi, the security firm Intel credited with first disclosing the vulnerability, arrived at the same conclusion... Making matters worse, unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware... The packets bypass the OS completely.

The article adds that Intel officials "said they expect PC makers to release a patch next week." And in the meantime? "Intel is urging customers to download and run this discovery tool to diagnose potentially vulnerable computers."

Saturday Ars Technica found more than 8,500 systems with an AMT interface exposed to the internet using the Shodan search engine -- over 2,000 in the United States -- adding that "many others may be accessible via organizational networks."
This discussion has been archived. No new comments can be posted.

Intel's Remote Hijacking Flaw Was 'Worse Than Anyone Thought'

Comments Filter:
  • by fahrbot-bot ( 874524 ) on Sunday May 07, 2017 @03:39PM (#54372563)

    "Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.

    He and I have different definitions for the word "worked".

    • by chispito ( 1870390 ) on Sunday May 07, 2017 @04:15PM (#54372749)

      "Authentication still worked" even when the wrong hash was entered, Tenable Director of Reverse Engineering Carlos Perez wrote.

      He and I have different definitions for the word "worked".

      The best phrasing would be that authentication "succeeded" despite the wrong password. You still get the idea.

    • by hey! ( 33014 )

      Well, if you're going to pick semantic nits, how about it being "worse than anyone thought." That would, from a pedantic point of view, be a stroke of luck.

      The worst case would be where the flaw persisted for some time with some people being aware of its severity.

      • Well, if you're going to pick semantic nits, how about it being "worse than anyone thought."

        It's more likely that this worked better than anyone thought. I mean, instant root access to any Intel-run PC? It's every intelligence agency's and hacker's wet dream. No way this was an accident.

        • by arth1 ( 260657 )

          It's more likely that this worked better than anyone thought. I mean, instant root access to any Intel-run PC?

          Not any Intel PC. Only those that have vPro capabilities with AMT support, are from 2010 or newer, have AMT configured and enabled, and have the management port exposed.
          Because it's not much use unless you've also purchased the remote management software from Intel that allows using the functionality, it's not all that common to find it enabled.

          • by smallfries ( 601545 ) on Monday May 08, 2017 @06:07AM (#54375123) Homepage

            You know that Intel processors without AMT still have the capability but it is disabled in software...

            • You know that Intel processors without AMT still have the capability but it is disabled in software...

              Every processor has to accept microcode updates. Pentiums, Skylakes, AMD's.
              During the life of the cpu, bugs or buglets are detected. The cpu vendor provides a microcode update that the motherboard bios sends to the processor. The microcode update corrects instructions, or even activates or can add a limited amount of new instructions.
              This will be the entry point for future hackers where the CPU is installed in non-uefi managed systems.

              • It's not always the bios. We have a problem at the moment with a lab full of Skylake machines. Originally it was supposed to run debian, but uploading the microcode binary blob didn't work properly. There are only two options: grab the raw updates from Intel and overwrite the init system to insert shortly after boot, or run Ubuntu which has the binary blobs already installed. For now we have to run with Ubuntu because nobody had time to sit and go through the Intel raw update to package it for the lab.

                It's

    • He and I have different definitions for the word "worked".

      Come on, Type I and Type II errors are so easy to mix up. ;)

    • by msauve ( 701917 )
      When there is no authentication, one can't claim that it worked in any sense.
      • by Dunbal ( 464142 ) *
        Except for the guys whose job it was to subvert the authentication process.
      • When there is no authentication, one can't claim that it worked in any sense.

        Actually, there's a difference in this case.

        First, if you're using a normal browser, you cannot actually facilitate this bug. It's impossible. So entering a blank password at the authentication prompt - it won't work.

        The reason it works is because you need to modify the HTTP headers (which is probably why it hid for so long). Remember in HTTP authentication, what gets sent is a hashed value of the username, password, nonce, and realm. It's well known how it's done, so it's not terribly secure to begin with (unless you do it over SSL), but that's HTTP authentication.

        The bug is that you need to send a HTTP authentication header with nothing. A normal browser won't do this because it will always send a hash, so you needed a proxy that strips off the hash from the header and passes everything else through.

        Of course, the bug is in the way it compares the hashes - as in, comparing the entered hash with its length to a strcmp() style function - the blank header forces the compare two strings of zero length returning authenticated status.

        Yes, it's a serious bug, no, it's not as stupid as entering a blank password. One does wonder if other web applications are just as vulnerable, though - since I'm sure this bug is present in many other things as well (after all, a blank authentication header doesn't happen in the normal case - a browser will return something).

    • by raymorris ( 2726007 ) on Sunday May 07, 2017 @07:36PM (#54373569) Journal

      This much more common mistake than one might think. A *lot* of applications will accept an empty password. It's one of the more common of the 90,000 or so vulnerabilities that we test for.

      Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative - what does it do with incorrect input? If a program retrieves a web page, what if it's empty? What does a searching or sorting program do when asked to aort or search an empty list, or a list of just one item? That stuff doesn't get tested much.

      • Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative

        How would you solve that problem?

        • White list instead of black list approach? Often times, programmers use black list approach which is cheaper and will not be adequate to test negative (no way to know all cases). If they do white list approach, it automatically rejects negative cases. Of course, the rejection (exception) handler must be included.

          • I'm not sure how to apply that to this situation.......
            • I'm not sure how to apply that to this situation.......

              Sometimes, white list approach looks similar to black list approach. However, in white list, you apply/check for known conditions. One solution, as others have stated, is to use the length of known string (calculate_hash) instead of user input (response). But this would give a reverse situation (could be a bug) -- will accept and pass anything (response is empty or not) if the calculate_hash is empty by itself. Another way for this situation is to validate the input -- not null or empty -- before calling st

              • The programmer who did this (if with naive intention) does not fully understand the function and may expect that strncmp() to verify the inputs for him/her.

                Yeah, not understanding the APIs you call is a serious cause of security flaws.

        • That's a good question. Perhaps, if you managed to create an environment where tests are expected and used in useful way, one could add an expectation to have an equal number of "not" tests, of tests showing what happens when input is not good, that the software does not do things when it shouldn't. That may get developers more into that frame of mind. The famous "goto fail" might have been avoided.

          Mature software development includes peer review followed by QA testing. Perhaps mature software development s

        • One of the many reasons people have gone to TDD ( https://en.wikipedia.org/wiki/... [wikipedia.org] )
      • Programmers get so focused on making things work

        Except for DRM programmers, who get so focused on making things not work.

  • by Anonymous Coward on Sunday May 07, 2017 @03:49PM (#54372613)

    Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.

    • by Dogtanian ( 588974 ) on Sunday May 07, 2017 @05:27PM (#54373115) Homepage

      Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.

      Coincidentally, around six weeks back, I bookmarked this article, originally written in 2016 [hackaday.com]. Notably, it says that:-

      Five or so years ago, Intel rolled out something horrible. Intel’s Management Engine (ME) is a completely separate computing environment running on Intel chipsets that has access to everything. The ME has network access, access to the host operating system, memory, and cryptography engine. The ME can be used remotely even if the PC is powered off. If that sounds scary, it gets even worse: no one knows what the ME is doing, and we can’t even look at the code. When — not ‘if’ — the ME is finally cracked open, every computer running on a recent Intel chip will have a huge security and privacy issue. Intel’s Management Engine is the single most dangerous piece of computer hardware ever created.

      Pedantry; it doesn't appear to be on every Intel chip, only those with vPro enabled(?) Still a horrible idea.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Intel Management Engine doesn't work like that. It's not something that gets applied in the UEFI or BIOS firmware. It's a completely separate processor running a proprietary and trade-secret operating system with control over much of the system resources alongside the x86 boot chain. This is specifically for security reasons: Intel ME is sold as a remote-control solution for businesses that need to maintain control over their computers even if the x86-side boot chain has already been compromised by malware.

    • Putting Internet accessible code running over the operating system was a terrible idea and this is the predictable outcome.The implementation was totally brain dead and wasn't even tested beyond "works in correct usage cases." This is the reason projects like Libreboot exist.

      What are the chances that the NSA knew about this loophole and profited from it? Is it 100% ?

  • by Anonymous Coward on Sunday May 07, 2017 @04:05PM (#54372687)

    (What? I get that security is hard and that sometimes there are unforeseen vulnerabilities. But... you can enter any text as the password, and it accepts it? Did no one at Intel test a wrong password at any point? This isn't a bug, this is outright negligence.)

     

    The article is a bit confusing regarding this, but no, you can't send an empty password. That's because when a browser does digest authentication it doesn't actually send the password, or even a password hash, to the web server.
     

    The browser sends instead a response MD5 hash computed on a string composed of various items, including a variable nonce sent by the server, in addition to the password, for example:
     

    response=MD5(MD5(username:realm:password):nonce:MD5(method:digestURI))
    https://en.wikipedia.org/wiki/Digest_ac ... entication
     

    This means a normal browser would never send an empty response, even when you enter an empty password. It would always send a 32 hex digit MD5 hash looking like this:
     

    response="6629fae49393a05397450978507c4ef1"
     

    The server would then compute the same hash, and compare them. If they are equal, it allows login, if they are different it denies login.
     

    The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:
     

    strncmp(string1, string2, N)
    http://www.cplusplus.com/reference/cstring/strncmp/
     

    And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:
     

    strncmp(computed_hash, response, strlen(response))
     

    So when it compared a real hash generated by a browser it would do something like:
     

    strncmp("6629fae49393a05397450978507c4ef1","d3d4914a43454b159a3fa6f5a91d801d", 32)
     

    This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn't match, and it would reject the empty password or invalid password.
     

    So anyone testing this from a browser would find it works perfectly.
     

    The problem is what happens if you don't use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this:
     

    strncmp("6629fae49393a05397450978507c4ef1","",0)
     

    This means the function will compare the first 0 characters between the two strings. So it is equivalent to:
     

    strncmp("","",0)
     

    Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal.
     

    What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings.
     

    Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don't need to supply a length parameter, like this:
     

    strcmp(string1, string2)
    http://www.cplusplus.com/reference/cstring/strcmp/

    • The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:

      strncmp(string1, string2, N)

      And applied it to the computed hash and the hash response received from the browser, with N set to the length of the response received from the browser, so something like:

      strncmp(computed_hash, response, strlen(response)) ...

      What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, befor

      • by mikael ( 484 )

        Visual Studio complains about the use of strcpy, strncmp, and insists on Microsoft's strcpy_s, strncmp_s variants, which seem mostly to insist on an additional maximum length to be specified.

    • by 140Mandak262Jamuna ( 970587 ) on Sunday May 07, 2017 @05:01PM (#54372977) Journal
      strcmp() has its own vulnerability. By sending a string without the terminating '\0' you make the strcmp() function read past the buffer. So the right thing to do is switch the arguments around, so that the length is computed from a known valid string, not from the untrustworthy response string.

      strncmp(response , computed_hash, strlen(computed_hash)) would be good. Or, hardwired a lower limit to avoid comparing strings less than 32 bytes.

      • strcmp() has its own vulnerability. By sending a string without the terminating '\0' you make the strcmp() function read past the buffer.

        Only if the string you are comparing it to, which was generated locally, is ALSO not null terminated.

        Regardless, the right thing to do with strncmp() is to use either the proper number of digits for the hash (which you can also expect to get with strlen(computed_hash)) or the size of the buffer that received the response.

        • strncpy is just broken. Period.

          It should complain if there is no null termination in the first string. The code should work, it just does not work around the bug in strncpy.

          Very much like strncpy not adding a null if it is N long.

          Lots of C grade rubbish that we still live with.

          • by chihowa ( 366380 )

            The code shouldn't always work because it depends on receiving a valid response from the untrustworthy browser.

            Using strlen(response), when the contents of response are outside of your control and you know that the correct length is strlen(computed_hash), is ridiculously sloppy for anybody, best especially somebody writing a security system.

          • by fisted ( 2295862 )

            strncpy is just broken. Period.

            Sorry, but you're full of shit.

            It should complain if there is no null termination in the first string.

            And how, pray tell, do you imagine it to be able to do that?

            Very much like strncpy not adding a null if it is N long.

            You don't understand what strncpy is meant for, but I suppose it's par for the course. Hint: strncpy is not supposed to be a "safe" variant of strcpy.

            Lots of C grade rubbish that we still live with.

            Yeah. And those programmers...they're even worse.

    • by Eluan ( 788868 )
      That is exactly the same bug that allowed the Nintendo Wii to be hacked in 2007. This makes me think about how long this has been abused in the wild.
    • What the programmer should have done

      You're assuming that this was an accident rather than a backdoor.

      • I agree ooloorie, this couldn't be an accident.

        This bit of code would've been identified as super-important when Intel (or whoever) was writing it, and it's too obvious a bug to have been unintentional. It's made to _look_ like an accident.

        To Intel: What's the name of the programmer who made the mistake? What does their other authentication coding look like? Are they a junior developer? Can we scour their github history (if any) and see if they really are that stupid? Who was the project manager for this so

        • by Raenex ( 947668 )

          I agree ooloorie, this couldn't be an accident.

          This bit of code would've been identified as super-important when Intel (or whoever) was writing it, and it's too obvious a bug to have been unintentional. It's made to _look_ like an accident.

          *snort* Shit like this happens all the time, in companies big and small. There's no guardian angel sitting over people's shoulders making sure code is identified as "super-important" and knowledgeable about all the ways C can fuck you over.

          If you wanted to put a back door in, making it so trivial to activate would be just as incompetent.

    • This whole story I think is a bit overblown. We use AMT where I work - recently I went to a client management event called "midwest management summit" - clients being PC/Mac devices.

      Anyhow in one of the AMT seminars I was the only one who raised my hand when asked who uses this (there were customers as big as Sprint, and Wells Fargo in the same room).

      The other thing - its not totally clear if this affects "Admin Control Mode" or "Small Business Mode" - most enterprises use admin control mode - as far as I k

  • by NuclearCat ( 899738 ) on Sunday May 07, 2017 @04:07PM (#54372703) Journal
    When companies will bear responsibility for flaws in such features, as AMT encrypted and obfuscated from 3rd party analysis and management, and enabled by default, and for such screw ups they will pay hefty fines, they will think twice, before making features work such way.
    • You say that as if there's any chance in hell of companies taking any real responsibility for shitty products. Fines are viewed as a cost of doing business and profit margins are adjusted accordingly. If the company doesn't get caught, it just means their profits are higher than expected due to the cost savings.

  • by Anonymous Coward on Sunday May 07, 2017 @04:27PM (#54372801)

    see e.g. https://hardware.slashdot.org/story/15/01/29/2241214/fsf-endorsed-libreboot-x200-laptop-comes-with-intels-amt-removed

    Moneyquote:

    "The ME and its extension, AMT, are serious security issues on modern Intel hardware and one of the main obstacles preventing most Intel based systems from being liberated by users."

    But hey, the FSF and Stallman are just overreacting hippies right? RIGHT?

  • by Anonymous Coward

    Russian and Chinese government agencies have been passively or actively promoting the development of a domestic semiconductor industry.

  • Any way to disable this in Linux?

    • Any way to disable this in Linux?

      No it exists above the normal operation of the computer, it is basically a separate secret computer inside your computer to remotely control and monitor you, and will run even when the computer is turned off (same sub-system as wake-on-lan). You need to disable it in the BIOS.

  • I have a Q170 chipset board at home and it's supposedly vulnerable, but I like having the ability to remotely control my PC (Server) from bootup to bios to Windows. If it's on a home network behind a firewall, this shouldn't matter.

  • Whoopsie? No way (Score:4, Insightful)

    by JustAnotherOldGuy ( 4145623 ) on Sunday May 07, 2017 @06:34PM (#54373349)

    " AMT makes it possible to log into a computer and exercise the same control enjoyed by administrators with physical access [and] was set up to require a password before it could be remotely accessed over a Web browser interface. But, remarkably, that authentication mechanism can be bypassed by entering any text string -- or no text at all..."

    I find it hard, very very hard, to believe that this was an accident or just the result of stupid coding. This was either deliberate or was some carefully planned subversion somewhere along the tool chain.

    • by gweihir ( 88907 )

      I understand the sentiment, but I disagree. This is far too easy to find for that. It is very surprising it took so long. The right way to do backdoors is to make _subtle_ errors that cannot easily be found without special knowledge. That way, they stay useful for a long, long time. No, this is likely just extreme incompetence.

      • I understand the sentiment, but I disagree. This is far too easy to find for that. It is very surprising it took so long. The right way to do backdoors is to make _subtle_ errors that cannot easily be found without special knowledge.

        And maybe there's one of those present too, but for now everyone is congratulating themselves on finding this one without realizing there's another one that hidden better.

        -

        That way, they stay useful for a long, long time. No, this is likely just extreme incompetence.

        You may be right, but I'm skeptical in the extreme.

        • by gweihir ( 88907 )

          Well, possibly. I think it would have been better to keep attention away from the whole thing, but it could have been some kind of "detector". I still think that is too complicated and one thing competent TLAs understand is KISS. Of course, US intelligence skill has been going down the drain, and maybe they did this as you describe. Would still be incompetence, just somewhere else.

          It is a shame we will likely never find out.

  • In case you were wondering, AMT allows you to access the screen, keyboard, and mouse of your machine through VNC as if you had a network KVM on that machine. It seems to use the VNC protocol even. Network KVMs are expensive specialty items, and something like AMT is a cleaner, simpler way of accomplishing the same thing.

    It's a shame Intel messed up and gave this feature a bad name. I hope they'll fix the problems and/or other motherboard makers will come out with a safer and improved version of it.

  • by gweihir ( 88907 ) on Sunday May 07, 2017 @06:57PM (#54373429)

    Now one wonders what great "security features" Intel has places in their network cards, chipsets and CPUs. This really is on the most stupid level possible. They cannot even have done an internal review of this code that deserves the name before putting it into production.

    • by AmiMoJo ( 196126 )

      I've got an Intel motherboard that is vulnerable. I contacted their support and they gave a date of 12/05/2017 for information on what fixes they are going to offer.

      Intel don't make motherboards any more. Mine is a legacy, unsupported product now. They better fucking fix it anyway.

  • One of our devices comes with control port open; you can enter commands and they will be executed according to your privileges. Besides "login" very few commands should work for the default user... except external software interacting with the device still doesn't support logging in, so the default privileges are set to maximum. You can still log in... to lower your privileges.

  • Active Management Technology... it sounds so much like ActiveX, and equally porous it would seem.

  • by BoRegardless ( 721219 ) on Sunday May 07, 2017 @08:34PM (#54373765)

    We succumb to the overlords when we use proprietary software!

  • by OFnow ( 1098151 ) on Sunday May 07, 2017 @09:11PM (#54373907)
    The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?
    • The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?

      Only if you have a machine specifically made to be a workstation. Unless it is at work, you probably only have one if you have ThinkPad, Macbook Pro or another high-end business or workstation laptop.

  • by mcswell ( 1102107 ) on Sunday May 07, 2017 @10:19PM (#54374065)

    The Intel-recommended "mitigation" until the patch is released involves "Unprovisioning clients". What the ___ does that mean? They provide software to do it, but what exactly are the effects? (And yes, I did a web search, but it was unenlightening.) There is a wikipedia article here
            https://en.wikipedia.org/wiki/... [wikipedia.org]
    on "provisioning", but it talks about seven different kinds of provisioning, and it's not clear which one the Intel doc is talking about. Nor is it clear from reading that article what the effects of UNprovisioning would be. Loss of ability to go on the web? Inability to download antivirus updates? Is it reversible, when the fix from Intel comes out? (and if a computer is "unprovisioned", can you even get the fix from Intel when it comes out?)

    • by Lehk228 ( 705449 )
      it means disconnecting your router from the internet
  • by ayesnymous ( 3665205 ) on Sunday May 07, 2017 @11:48PM (#54374309)
    When I was looking at buying a Dell or HP laptop a couple years ago, they both gave me the choice of disabling vPro. AMT is a subset of vPro. So you could disable it if you wanted. Not sure why anyone would choose to have it enabled. And from what I've read, if you have them disable vPro at the factory, it's not possible to enable it later.

"And do you think (fop that I am) that I could be the Scarlet Pumpernickel?" -- Looney Tunes, The Scarlet Pumpernickel (1950, Chuck Jones)

Working...