Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the in-the-chips dept.

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

106 of 200 comments (clear)

  1. I don't think you know what that word means. by fahrbot-bot · · Score: 5, Funny

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

    --
    It must have been something you assimilated. . . .
    1. Re:I don't think you know what that word means. by chispito · · Score: 3, Informative

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

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    2. Re:I don't think you know what that word means. by hey! · · Score: 1

      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.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    3. Re:I don't think you know what that word means. by K.+S.+Kyosuke · · Score: 2

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

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

      --
      Ezekiel 23:20
    4. Re:I don't think you know what that word means. by msauve · · Score: 2

      When there is no authentication, one can't claim that it worked in any sense.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    5. Re:I don't think you know what that word means. by JustAnotherOldGuy · · Score: 1

      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.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    6. Re:I don't think you know what that word means. by Dunbal · · Score: 1

      Except for the guys whose job it was to subvert the authentication process.

      --
      Seven puppies were harmed during the making of this post.
    7. Re:I don't think you know what that word means. by Anonymous Coward · · Score: 1

      Authentication did not succeed. Authentication was bypassed when the response token was zero length (or any substring of the genuine response token, but the zero length one allows you to make a guess without prior knowledge and hit with 100% accuracy).

    8. Re:I don't think you know what that word means. by arth1 · · Score: 2

      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.

    9. Re:I don't think you know what that word means. by tlhIngan · · Score: 5, Informative

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

    10. Re:I don't think you know what that word means. by smallfries · · Score: 4, Interesting

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

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    11. Re:I don't think you know what that word means. by lsatenstein · · Score: 1

      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.

      --
      Leslie Satenstein Montreal Quebec Canada
    12. Re:I don't think you know what that word means. by smallfries · · Score: 1

      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 a shitty situation, and it will probably get worse. The microcode patch mechanism destroys any chance of building a reproducible environemnt in the lab, knowing that there is a whole other black-box sitting on the chipset makes the situation even worse...

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
  2. Predictable outcome by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:Predictable outcome by Dogtanian · · Score: 4, Interesting

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

      --
      "Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
    2. Re: Predictable outcome by sexconker · · Score: 5, Insightful

      "Let's see a suit and a recall of millions of laptops. I'd love to see Intel out of business"
      Apple laptops aren't effected, even if they run Windows in a VM. The chips that Intel ships to Apple don't have AMT enabled.
      Of course if there is a massive revolt against the OEMs who implemented this because Corporate IT lazy-asses requested it, that means more MacBooks sold, which of course will continue to run on AMT-Free Intel chips.
      Win-Win... but not for Windows.

      The chips that Intel ships to Apple don't have AMT enabled.

      I'm destroying some mods on this thread by posting, but I need to correct your very wrong post.

      It's still physically present. No one except Intel knows what is actually baked into it and what's actually turned on at any given point. That's the fucking problem. That's why we're in this mess to begin with.

    3. Re:Predictable outcome by sexconker · · Score: 4, Informative

      It's still physically in every chip from the last decade or so. Intel just disabled features based on the SKU. Whether AMT is disabled or "disabled" is unknown.

    4. Re:Predictable outcome by Anonymous Coward · · Score: 3, Interesting

      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.

      Oh and AMD did the same thing - AMD CPUs from 2013 onward include a PSP or Platform Security Processor whose source is closed and is a black box anyway. It will hold the x86 cores in RESET until it can find a valid and cryptographically-signed firmware blob to run. Oh, and both the AMD PSP and the Intel ME implement code-signing for the x86-side firmware, which specifically prevents Libreboot from working on those platforms. CPU manufacturers do not want anyone other than licensed-and-bonded motherboard manufacturers from writing firmware code.

    5. Re:Predictable outcome by lsatenstein · · Score: 1

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

      --
      Leslie Satenstein Montreal Quebec Canada
  3. Re: Dear Intel by muffen · · Score: 1, Redundant

    This is unlikely to be a deliberate backdoor, it's much more likely the result of a mistake. However, if you aren't going to buy anything that has had a remote code exec vuln, you should probably consider using pen and paper, exclusively!

  4. Ars story highest voted comment by Anonymous Coward · · Score: 5, Informative

    (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/

    1. Re:Ars story highest voted comment by Ungrounded+Lightning · · Score: 1

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

      That's indeed the correct solution.

      But he also could have used strncmp() properly. The strn*() routines' N argument is primarily to keep the routines from overrunning buffers (secondarily look at a subset of a string). So N should have been the expected number of characters for the hash:

      strncmp(computed_hash, response, 32) // (Or a suitable manifest constant.)

      Just taking the string length from the good string, instead of the argument, would work, too:

      strncmp(computed_hash, response, strlen(computed_hash))

      Or sizeof(the computed_hash buffer) - but for that one you have to watch out that you don't get the size of a pointer. That would also break it by only comparing the first few bytes (which would make it difficult, but not impossible, to exercise).

      --
      Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    2. Re:Ars story highest voted comment by 140Mandak262Jamuna · · Score: 3, Interesting
      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.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    3. Re:Ars story highest voted comment by Ungrounded+Lightning · · Score: 1

      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.

      --
      Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    4. Re:Ars story highest voted comment by mikael · · Score: 1

      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.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    5. Re:Ars story highest voted comment by Eluan · · Score: 1

      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.

    6. Re:Ars story highest voted comment by ooloorie · · Score: 2

      What the programmer should have done

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

    7. Re:Ars story highest voted comment by enrique556 · · Score: 2

      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 software, and who was this idiot's supervisor? Who was responsible for reviewing their code?

      Intel's customers should consider this malicious until proven otherwise.

    8. Re:Ars story highest voted comment by dejaniv · · Score: 1

      The reason why programmer used strncmp() is probably because static analysis tool complained that strcmp() is insecure. This one and other string functions that do not take the size of the input/output buffer (strcpy(), strstr(), etc.) would trigger that warning because they are considered insecure by most standards. This is because lack of null termination in the strings could cause buffer overrun when these insecure functions are used, leading to arbitrary code execution or data corruption. Having an extra parameter for this doesn't inherently solve the problem but at least it makes programmer thing about security implications.

      What the programmer had to do as one of the steps in writing secure server code was sanitizing the input. Any information coming from client that is used in the server's code must be checked for validity before use. Failing to do so is also something that can be caught by static code analysis. At very least I would expect code like this to had been reviewed by security experts at Intel before shipping.

    9. Re:Ars story highest voted comment by paazin · · Score: 1

      if the hash is constructed using a nonce and each subsequent request uses a new nonce, the timing attack wouldn't get much useful

    10. Re:Ars story highest voted comment by Raenex · · Score: 1

      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.

  5. Responsibility for such flaws by NuclearCat · · Score: 5, Insightful

    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.

    1. Re:Responsibility for such flaws by GrumpySteen · · Score: 2

      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.

  6. We've known for years that AMT was a risk by Anonymous Coward · · Score: 5, Informative

    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?

    1. Re:We've known for years that AMT was a risk by Tough+Love · · Score: 1

      Why can't both things be true?

      Because one of them is nonsense promulgated mainly by special snowflakes with vested interests.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:We've known for years that AMT was a risk by Anonymous Coward · · Score: 1

      Why can't both things be true?

      Because one of them is nonsense promulgated mainly by special snowflakes with vested interests.

      Yes. So far as I can determine, most of the flak and hatred directed at FSF/RMS comes from the huge crowd who just want to say "oooh so SHINY!" RMS is asking them to actually *think things through* - you know, like adult responsibilities, not like children at Christmas - and actually doing that "spoils" their shiny.

      Computing is harmed by large numbers of users who want a general-purpose machine to be an appliance because they can't understand that these two things are not really compatible. They are easy to identify. They're the users who can use the same kind of systems for years and years, yet never develop any skill or knowledge beyond the bare minimum necessary to complete a specific task (not even accidentally picking up new information - that really takes work heh). They're the ones who won't even try to Google a question, not even when it's easy to find and the answer is dead simple.

      In general they resent the idea that they should ever, under any circumstances, invest the slightest bit of effort towards their own experience. The very suggestion pisses them off, even when it really is both the easiest and simplest solution. They say things like "I am not a computer expert!" when nothing even approaching expertise is needed, only basic literacy.

      They're helpless (not just with computing) and they like being that way. They don't want to taste solid food because they like the attention of having "Mama" spoon-feed them. The vested interests you mention encourage this through marketing that focuses on "ease of use" over robustness. Dumb consumers are an ideal audience for them -- marketing and PR work most effectively on an uninformed audience that cannot think critically.

      So to tell them that their special shiny not only has serious flaws, but that these flaws were easily predictable years before they were ever implemented, well they don't perceive that as useful information that assists in good decision-making. No, they perceive that as a bucket of ice-water dumped on their heads. They react to inconvenient facts the way all small-minded people do: by getting upset. This mentality resists correction and your best bet is to minimize interaction with such people.

  7. Re: Dear Intel by Anonymous Coward · · Score: 1

    You know, a really well-crafted backdoor will look exactly like this. When they are found out they can still say "Oops! My bad" then.

  8. And people wonder why . . . by Anonymous Coward · · Score: 2, Insightful

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

  9. Re:There are no comments by wonkey_monkey · · Score: 1

    Err... no?

    --
    systemd is Roko's Basilisk.
  10. Disable by itamihn · · Score: 1

    Any way to disable this in Linux?

    1. Re:Disable by Carewolf · · Score: 1

      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.

    2. Re:Disable by mikael · · Score: 1

      http://web.archive.org/web/201...

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  11. Re:It's time to hold engineers liable by Ungrounded+Lightning · · Score: 2

    It is time to finally star holding engineers criminally and civilly liable, ...

    Force them to chose between risking jail for a bug or being fired for not following the Pointy Haired Boss' instructions to skip the tetsting and get the damn thing delivered?

    What a great idea. Put most of the engineers who would actually do what you want out of work and leave the field to those to dumb to notice or too psychopathic to care.

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
  12. Thanks for the comment. by Futurepower(R) · · Score: 1

    Interesting info, APK.

  13. Q chipset boards by valnar · · Score: 1

    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.

    1. Re:Q chipset boards by Khyber · · Score: 1

      As if firewalls are bulletproof.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    2. Re:Q chipset boards by Lehk228 · · Score: 1

      unless the firewall is running on an intel chip too, then you are pretty fucked.

      --
      Snowden and Manning are heroes.
  14. Re: Dear Intel by mikael · · Score: 4, Interesting

    This is what all backdoors look like. "Ooops, we accidently encrypt and decrypt the password and write it out at the end of the file". "Whoops, we missed out a break statement in the selection of the encryption algorithm, it always defaults to the legacy easily broken encryption method". "Oh, shooot, we forget to add the menu option to the router to filter out multicasts, anyone can send a SSDP multicast to that address and get a list of hosts returned."

    Like Microsoft's Windows OS firewall doesn't allow blocking of Microsoft telemetry servers. Wonder why? What could be so harmful in blocking a data stream of a few hundred bytes/second?

    --
    Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  15. Re: Predictable outcome (only in windows?) by Anonymous Coward · · Score: 5, Informative

    No, Intel AMT runs completely independently of the operating system. It doesn't matter whether the operating system is Windows, Linux, BSD, or anything else.

    In fact, it's even worse. Intel AMT can still be running while the computer is off (but still plugged in). See

    https://fsf.org/blogs/community/active-management-technology

    Let me say it again: your computer can be pwned while it's off! You don't need to have anything running at all, because Intel AMT keeps running in the background as long as the machine is plugged in.

  16. Re:Free tool "openSORES" too to disable AMT by byornski · · Score: 1

    I think you miss the point. It runs at the most basic hardware level, if it's enabled and supported by your motherboard. Having to install extra software to enable it suggests your motherboard does not directly support it, so this test is meaningless. It does not require additional software to work....

  17. Whoopsie? No way by JustAnotherOldGuy · · Score: 3, Insightful

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

    --
    Just cruising through this digital world at 33 1/3 rpm...
    1. Re:Whoopsie? No way by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Whoopsie? No way by JustAnotherOldGuy · · Score: 1

      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.

      --
      Just cruising through this digital world at 33 1/3 rpm...
    3. Re:Whoopsie? No way by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  18. AMT sounds really useful by ooloorie · · Score: 1

    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.

  19. Re: Dear Intel by phantomfive · · Score: 2

    However, if you aren't going to buy anything that has had a remote code exec vuln, you should probably consider using pen and paper, exclusively!

    Uh, a computer with no OS installed should never have a vulnerability. Ever.
    It's not a hard thing to do, there are plenty of models that have succeeded, even from crappy companies like Compaq.

    If you're going to release something that allows hackers to have ultimate, undetectable control over the computer, you better give it a security audit. All indications are that Intel does not have proper security processes for their systems. This is just one example.

    --
    "First they came for the slanderers and i said nothing."
  20. Does not get much more incompetent than this by gweihir · · Score: 2

    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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Does not get much more incompetent than this by AmiMoJo · · Score: 2

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  21. Re:It's time to hold engineers liable by sjames · · Score: 4, Insightful

    The employers aren't currently held responsible either.

    The problem is that the developers have no power over management to make them do the right thing. Unless and until they do, it isn't reasonable to hold them responsible. They can't make their employer do QA tests, they can't make the employer push the schedule back, and they can't prevent the premature release of a product.

  22. Happens... by SharpFang · · Score: 1

    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.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  23. Re:Incorrect & "you're late to the game..." by byornski · · Score: 1

    You've clearly got some hackneyed version of it as it runs without drivers on supporting hardware. Sounds like you've got some sort of winmodem-style version of this. Read the summary...

  24. C langage guilty again. by aberglas · · Score: 1

    Indeed.

    This is yet another security bug produced directly by the archaic C programming language. If this had been any other language the bug wold not have happened, despite the incompetent programmer. Null terminated strings! Wild pointer usage!

    C is evil.

    1. Re:C langage guilty again. by Tranzistors · · Score: 1

      Well, yes. Apparently the job required wrench and rivet fastener.

  25. Lack of negative testing - extremely common by raymorris · · Score: 5, Interesting

    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.

    1. Re:Lack of negative testing - extremely common by phantomfive · · Score: 1

      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?

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Lack of negative testing - extremely common by Anonymous Coward · · Score: 1

      IMHO when the cost of not testing > cost of testing.

      Right now, as things stand, getting compromised costs very little when compared to the cost of properly testing. The cost is going up, thankfully, albeit slowly.
       

    3. Re:Lack of negative testing - extremely common by parkinglot777 · · Score: 2

      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.

    4. Re:Lack of negative testing - extremely common by phantomfive · · Score: 1

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

      --
      "First they came for the slanderers and i said nothing."
    5. Re:Lack of negative testing - extremely common by parkinglot777 · · Score: 1

      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 strncmp() with similar arguments because you expect that the input (password) will always contain something -- white list.

      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.

    6. Re:Lack of negative testing - extremely common by phantomfive · · Score: 1

      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.

      --
      "First they came for the slanderers and i said nothing."
    7. Re:Lack of negative testing - extremely common by fox171171 · · Score: 1

      Programmers get so focused on making things work

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

    8. Re:Lack of negative testing - extremely common by coolsnowmen · · Score: 1

      One of the many reasons people have gone to TDD ( https://en.wikipedia.org/wiki/... )

  26. strncpy is broken, period. by aberglas · · Score: 1

    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.

    1. Re:strncpy is broken, period. by chihowa · · Score: 1

      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.

      --
      If you want a vision of the future, imagine a youtube comments section scrolling - forever.
    2. Re:strncpy is broken, period. by fisted · · Score: 1

      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.

      --
      CLI paste? paste.pr0.tips!
    3. Re:strncpy is broken, period. by Raenex · · Score: 1

      Sorry, but this is programmer idiocy not the fault of the language.

      The problem is the language. It's very low-level and full of easy to make errors. In any reasonably sane language that doesn't treat every CPU cycle as precious shit like this does not happen.

      KNOWN AND DOCUMENTED BEHAVIOR

      That C's error-prone functions have been documented and can be used correctly given enough care and experience doesn't excuse the language or prevent these kinds of errors from happening in the real world. Yes, in your mythical world where only perfect and experienced C programmers write code this isn't a problem.

    4. Re:strncpy is broken, period. by fisted · · Score: 1

      strncpy is not supposed to be a "safe" variant of strcpy.

      strncpy is NOT a safe version of strcpy.

      Yawn. Practice your reading comprehension.

      --
      CLI paste? paste.pr0.tips!
  27. Active xxx by Tough+Love · · Score: 1

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

    --
    When all you have is a hammer, every problem starts to look like a thumb.
  28. Re:Why'd Intel Mgt. Engine come w/ my mobo? by byornski · · Score: 2
    For the more complicated functions that it can perform. But see this.

    Traffic on ports 16992-16995 are directly intercepted by Intel AMT within the chipset before being passed to the host operating system... once Intel AMT is in a configured and accessible state.

    and

    Intel AMT enables reliable power control of the platform, booting for a network based ISO image, integration Keyboard-Video-Mouse (KVM), and more.

    So a remote exploit could just consist of power cycling to boot from a external boot image. Only OS requests are sent to the OS, everything else is supposed to be caught at the hardware level.

  29. Stallman was Right by BoRegardless · · Score: 2

    We succumb to the overlords when we use proprietary software!

  30. Re: I block those ranges in my firewalls... apk by byornski · · Score: 1

    If you blocked them internally, your LAN was never vulnerable so I'm not quite sure what your point was. This is mainly aimed at the (relatively) small set of servers that may have these features in hardware and enabled, not home users. All you've showed was that you managed to enable a software based version of the vulnerability and then disable it in software.

  31. Discovery tool only Windows by OFnow · · Score: 3, Interesting

    The Discovery Tool from Intel is a Windows executable. So how about the rest of us, Intel? Are our Intel CPUs vulnerable?

    1. Re:Discovery tool only Windows by Carewolf · · Score: 1

      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.

  32. Re:Here's the FUNNY part (LOL @ U w/ proof) by BronsCon · · Score: 1

    I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

    Context matters. If I recall correctly, I go on to point out that no matter how good your work may or may not be, your toxic personality makes everything you touch toxic as well. Sort of like a serial killer chef who makes the most wonderful of soufflé... which just so happens to be lethal within an hour of consumption.

    --
    APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  33. Re: I don't run a LAN here (don't assume)... apk by byornski · · Score: 1

    Perhaps I wasn't clear. I mean internal port blocking at a switch level. Hardening windows will do nothing against the exploit proper. Blocking these ports at a hardware level is a mitagation until the firmware is patched.

  34. Re: "A look @ the future & the future IS now.. by byornski · · Score: 1

    Yes, secure for decades by the virtue that the processor predates the features(2008ish).

  35. Unprovisioning clients by mcswell · · Score: 2

    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/...
    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?)

    1. Re:Unprovisioning clients by Lehk228 · · Score: 1

      it means disconnecting your router from the internet

      --
      Snowden and Manning are heroes.
    2. Re:Unprovisioning clients by mcswell · · Score: 1

      Really? I could do that by unplugging the cable...

    3. Re:Unprovisioning clients by michael_wojcik · · Score: 1

      Essentially it means AMT will be disabled. "Provisioning" means "making AMT available for use"; unprovisioning is the the opposite.

      If the Intel tool[1] shows your system is provisioned, go ahead and unprovision it. Regardless of what you might be using AMT for in your organization, it's not worth the risk.

      The Intel tools[2] include some documentation which, while pretty bad, does help clarify some things.

      [1] Or some alternative, if you're not running Windows; unfortunately I have no idea what the alternative might be, because Intel's communication in this issue is abysmal. Their tools are crap and their instructions are crap, even for Windows, and if you're running anything else then ha ha fuck you. Really this is an appallingly poor response by a vendor, and Intel deserve every bit of bad press and more.

      [2] They can be downloaded from Intel here. Of course that page requires Javascript because it's impossible to provide downloads without Javascript. No, wait, it's because the people in charge of Intel's website are idiots.

    4. Re:Unprovisioning clients by mcswell · · Score: 1

      Thanks for the explanation! Oh, and my computer is a home computer, not any organization's computer that needs to be managed. IMO, this management thing should have come turned off out of the box, preferably with a hardware switch for security. If someone's managing a bunch of computers and needs this capability, they could jolly well go in and turn it on.

      Also, I'll go on record as saying Intel ought to hire you to write lucid explanations for them. Thanks again!

  36. Computer manufacturers let you disable AMT by ayesnymous · · Score: 3, Interesting

    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.

  37. Re: LEARN TO READ please... apk by byornski · · Score: 1

    Literally avoiding the issue that you weren't vulnerable anyway until you installed some other software. Perhaps you should have blocked the Intel site with some sort of hosts file?

  38. Re: Dear Intel by Wootery · · Score: 1

    This is what all backdoors look like.

    And perfectly executed assassinations look like accidents, but it's still more likely that grandpa just had a heart-attack.

    The point -- as to whether it's likely -- stands.

  39. Re:Yea but my work's good... apk by BronsCon · · Score: 1

    Trust also matters and a security "professional" who stabs someone in the back after supposedly reaching an understanding (the way you did me) is not trustrowthy. Neither is their software.

    You may be winning in your own mind, but when you do so by violating trust you're destroying your own brand. Security is a trust-based market and nobody trusts you.

    --
    APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  40. Re:It's time to hold engineers liable by upuv · · Score: 1

    Programmers are not considered "professionals" by standard bodies. They do not have the power or responsibility to reject or overrule management. If management wants to cut corners, reduce testing, end run around process etc. Then there is basically nothing they can do about it other than quit.

    To make programmers liable would result in a massive change in the industry. With the most noticeable impact being a dramatic increase in TTM and a massive blowout in costs. The industrial lobby would never allow this to happen. Nations that do not subscribe to these responsibility requirements will almost instantly become the new IT super shops.

    By making the company and not the developer liable you enable countries to actually have an IT industry.

    Civil engineering must occur in each nation. Software development does not. This simple fact makes liability very difficult to implement. Second reason is the calculation of damages. With civil engineering the cost of a problem is relatively easy to calculate. In IT systems where most companies hide the impact of a fault the ability to calculate impact cost is near impossible. Thus to compare civil eng with software dev is not a good comparison.

  41. Re:Yea but my work's good... apk by BronsCon · · Score: 1

    Why don't we just quote the entire post ? That gives a lot mofe context regarding what lead up to that comment, as well as what followed

    Such a "trustworthy" guy you are, no? The thread that comment came from, and what your troll brigade did to my karma immediately following it (which I recovered from in less than a week, mind you, because people seem to actually like having me here for whatever reason), really bear out how much trust you and your software deserve.

    --
    APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  42. Good question. Perhaps "not" tests, securit review by raymorris · · Score: 1

    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 should include security review and security testing. Just as you do peer review, have a security-focused person look over the code and run a test. Not just to catch issues, though it'll do that, but so the feedback helps developers think about those types of issues in the future.

  43. Re:At least 8500 systems exposed you cocksucker by Raenex · · Score: 1

    A query of the Shodan security search engine found over 8,500 systems with the AMT interface exposed to the Internet, with over 2,000 in the United States alone.

    Given the gazillions of computers on the Internet, that number is extremely small.

  44. Re:Please support open hardware by unixisc · · Score: 1

    How is the RISC-V platform in performance? Aside from the potential option of tossing 16 cores into a CPU? That, or the OpenRISC CPU - either of them should be able to satisfy one's requirement. Port FreeBSD onto that, and one has a solution

  45. Re:I trust your words quoted (you said it not I) by BronsCon · · Score: 1

    You say 1 thing quoted above & now something else

    Actually, as supported by evidence (e.g. the post you quoted, which I linked to), the "something else" you're claiming I'm just now saying was said in the very same post you are quoting out of context. That was my entire point.

    Reading through that conversation again did remind me of something, though. I shouldn't be speaking with the dead so, good day, sir. Enjoy the afterlife.

    --
    APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  46. how the fuck by strstr · · Score: 1

    such a complete exploit, it seems more like it was put there deliberately for the government to access...

    it makes no sense such exploit could come about by accident.

    obamasweapon.com

  47. Re:It's time to hold engineers liable by LordWabbit2 · · Score: 1

    Agreed, it's pointless blaming the developers when they are not the ones calling the shots. I have worked at a couple companies where the deadline for release was set in stone, regardless of ANYTHING else. The project went live and our currency ended up taking a bit of a dip because of the fvck up it caused on the stock exchange (and no, I was not part of THAT project thank god!). Also programming is NOT the same as engineering. Most engineering projects are planned WAY WAY better than 99.999% if I.T. projects, which makes it easier to hit the dead line etc. Now I am not an engineer (well, I was studying for it many moons ago, but I got sidetracked into software) so I may stand corrected, but I am pretty sure most engineering tasks don't hit a snag and grind progress down to a crawl. Look I am sure there are exceptions, but I have encountered weird ass bugs that take forever to hunt down, that was not part of the original project plan!

    --
    There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
  48. Re: "A look @ the future & the future IS now. by Brockmire · · Score: 1

    You've wasted your time with apk. He's never had a technical conversation, it's all fucking non-related hosts bullshit. He makes up a lot of shit. He really should have more supervision.

  49. Re: "A look @ the future & the future IS now. by byornski · · Score: 1

    I had had a few beers and wanted to see how far he'd argue his nonsense :D

  50. Re:It's time to hold engineers liable by sjames · · Score: 1

    Perhaps more to the point, employers aren't willing to pay for the planning stage. It's even worse for contract programming where they want a time table and a firm price before they've even hired you. There's no way that what should be 50 to 90 percent of the total project is going to be done for free up front and not get corners cut. If you add in enough fudge factor to get the planning in after signing, someone will inevitably undercut your bid and do a crap job of planning.