9 ms·

The hijacking flaw that lurked in Intel chips is worse than anyone thought

208 points by podiki 9y ago

lisper 9y ago
It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.
- benchaney 9y ago
  Because if you are going to do security wrong, why not do it really really wrong.
- megadollar 9y ago
  That's fine. I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. Take your attack vector to be that particular md5sum that you are making fun of. MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security. In addition to the fundamental technical deficiency you've demonstrated, people who opine on security threads while not quite understanding anything about computer security allow charlatans to sell "computer security". Every single comment like this lends credence to literal scam artists. ¹note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)
  - lightedman 9y ago
    "MD5 is not broken for the usage that you think it's broken for." Correct; it's broken for everything since we've got the computational power to make it essentially ineffective.
    - Xylakant 9y ago
      That's not entirely true. It's broken in the sense that for every hash given we can compute an input that produces this hash. Constructing a useful input (in this case a working exploit) is much less trivial. The complexity depends significantly on what the desired input should look like. It's easier for input that have the property that they can ignore chunks of the input (googles PDF example), but still hard for others.
      - megadollar 9y ago
        We cannot produce an input that produces an arbitrary given hash. Here's an easy counterexample: the all-zeroes md5sum. That's an even harder problem than the one I've claimed is entirely not solved. MD5 is still preimage and second-preimage resistant.
  - technion 9y ago
    The other way to look at this is.. MD5 is known to be a poor option. And every few years the practicalities of attacking it increase. And when the type of attack described here does become practical, all we'll be hearing is one side saying "they had ten years to fix this" and another side saying "but experts we consulted said it was fine". It is incredibly easy for whatever process builds a website with an MD5 hash of a download to instead display something else, so the cost trade off becomes: Cost: Virtually nil Mitigation: Currently minimal but has future potential That a company would look at that and say "I guess we'll make a choice to stick with MD5" says something, even if it doesn't say the website downloads are easily compromised. Alternatively, the parent comment could be pointing out that no hash signature that only exists on the download site itself offers value, and they would be better served offering a GPG signature or similar.
  - stevenh 9y ago
    Hello fellow ordinary person using an account created a year ago and finally posting today for the very first time with comically irrational outrage over the possibility of people ever moving away from md5sum thus rendering useless whatever subset of shady tools you or your employer has that we don't know about yet. Consider making innocuous comments in various threads for a few weeks before you switch to psyop mode next time.
    - coldtea 9y ago
      Tin foil much? As if what will ...really help NSA and co are 1-2 random comments of technical pedantry regarding MD5 on an insignificant (in the grand scheme of things) forum people go to discuss the latest startup news, JS frameworks, the benefits of functional programming, Golang, tech industry developments, and some CS related news.
      - chillingeffect 9y ago
        Sustained disinformation campaigns are a go-to strategy. Redirecting and confounding conversations are documented tactics. They don't even have to be particularly well veiled or surgically placed as their value derives from their volume.
  - heinrich5991 9y ago
    There are easy collision attacks against MD5. If they used a stronger hash, we would know that they couldn't have been coerced to use a hash that collides with a bad version of the update.
  - lisper 9y ago
    > I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. It's almost certainly a question of when, not if, I will be able to collect on that offer.
  - benchaney 9y ago
    The reason that people move away from a hash function when it looses collision resistance is that collision resistance serves as a measure of the security margin for preimage resistance. Cryptographic primitives are intended to be rotated out of use about 10-15 years before they become actually broken for their intended purpose. Unless you are willing to extend you bounty to the year 2030 it is means nothing. In addition, you are completely wrong about the harm caused by simplifying the rules of thumb for security. There is not good reason to ever use MD5 for this purpose, and saying "MD5 is ok in some cases" has the potentially to do far more harm than "never use MD5". > note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!) Don't act like you are doing GP a favor, second preimage is the attack that would cause a vulnerability in this usage of MD5. You are the one who is"opin[ing] on security threads while not quite understanding anything", so I think before the next time you condescendingly correct someone you should make sure you have a basic understanding of what you are talking about.
    - megadollar 9y ago
      You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb and you've since argued against a strawman. Did I ever say "MD5 is ok in some cases"? Aside: a preimage attack implies a second preimage attack.
      - benchaney 9y ago
        >You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb Not all devs are security experts, or can even afford to focus on security. To deny the value of rules of thumb is to deny that they need to consider security. > Did I ever say "MD5 is ok in some cases"? Oh, really? Were you not arguing that MD5 is ok if you only need preimage resistance? > MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security. Hmm. Seems like you were...
- nogbit 9y ago
  It's because both colliding files have to be specially prepared by the attacker, before they are published on a download site or presented for signing by a code signing scheme. https://www.win.tue.nl/hashclash/SoftIntCodeSign/ https://www.win.tue.nl/hashclash/SoftIntCodeSign/ Which means, the published MD5 on on the Intel site would have to be the hash that the attacker created. Though I'm sure there are better methods that Intel could implement.
CodeWriter23 9y ago
Interesting how this article steadfastly refers to the subsystem as AMT and never mentions Management Engine/ME. A deliberate ploy to redirect people away from discovering all the ME-disabling research and tech? Perhaps. This is what happens when "journalists" post copypasta from publicists.
- ars 9y ago
  I quote: "When AMT is enabled, all network packets are redirected to the Intel Management Engine"
  - jgaa 9y ago
    As far as I know, it's only doing this for the primary (on-chip) network interface. /Never/ use the primary NIC if you have a Intel CPU.
  - lima 9y ago
    Which is wrong, by the way. What actually happens is that a filter is installed on the NIC that redirects some packets (those addressed to the ME).
- khedoros1 9y ago
  AMT's an optional component of the ME, it's the part that enables remote management, and it's a flaw in AMT that they're describing. It seems reasonable to talk about the part that has a problem (although it wouldn't have been unreasonable for them to mention that it's part of the IME, of course).
- confounded 9y ago
  From the article: > When AMT is enabled, all network packets are redirected to the Intel Management Engine and from there to the AMT. The packets bypass the OS completely. The vulnerable management features were made available in some but not all Intel chipsets starting in 2010, Embedi has said. The vulnerability is in AMT, not ME (though I agree that the ME is an unnecessary security risk, and am well behind the current research to disable it).
Cyph0n 9y ago
There is a great comment linked at the bottom of the article that explains what exactly caused the authentication bug (it was strncmp!). Is there somehow a law that states that the higher the severity of a software bug, the simpler the reason behind it?
- mirimir 9y ago
  Yes, that is crazy. Checking for match based on the length of the input. If input is "", that matches anything.
- chmaynard 9y ago
  From the comment: 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...
  - benchaney 9y ago
    strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is deprecated and should not be used for new projects.
    - dom0 9y ago
      Yep, even if they had used memcmp/strncmp correctly the AMT would still be vulnerable to a timing attack here, which is probably even easy, because it runs on a low-power system with, I assume, not much background activity.
      - benchaney 9y ago
        In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.
benchaney 9y ago
I wish that this security incident would get more attention. It seems fundamentally unfair that some projects that are essentially volunteer labor get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets mostly ignored.
- rfugger 9y ago
  Being an advertiser has its privileges.
- DKnoll 9y ago
  If scrutiny improves the project it's ultimately a good thing.
  - d33 9y ago
    ...which is exactly why Intel chips should get it too.
    - DKnoll 9y ago
      Totally, but what I'm saying is it's not unfair, it's an inherent benefit of OSS.
geofft 9y ago
At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function. If you want to fix this, there's no strict need to move away from C (not that I'd particularly encourage you to stay, but if you have some reason to prefer C, you can solve this in C). There are a number of C libraries that give you a struct string {char *ptr; int len;} of some sort, from bstring to GLib. And there's always C++, too. What need does the Intel AMT firmware have for compatibility with POSIX string APIs? It's not running a POSIX OS, is it?
- code_sloth 9y ago
  Could you elaborate on why "treating the pointer to a string and the string length as separate vars" is dangerous to someone who hasn't done a lot of C?
  - pabl0rg 9y ago
    If you access a memory location beyond the end of the string, you can get all sorts of unexpected behavior. The string's length is something you'll pretty much always need to take into account.
    - DaiPlusPlus 9y ago
      Many libraries and systems (e.g. Win32) just go with null-terminated strings and their functions don't accept a length argument at all - so I wonder if some people never store the length simply because they don't believe they'll ever need it.
  - qb45 9y ago
    Because occasionally you use wrong length with wrong pointer and read or overwrite something you didn't want to. It's more convenient and safer to have these two variables packed together as a "string object" and have string functions operate on that - then they always know where the string starts and ends in memory.
Myrmornis 9y ago
Is the amount of attention this is getting commensurate with how interesting/surprising/consequential a security flaw it is?
- gpvos 9y ago
  No, it looks like it's not getting enough attention. (Well, OK, it is not terribly surprising.)
- DKnoll 9y ago
  I don't think it's just that the flaw exists, which alone is pretty bad, but how widely deployed it is in large enterprise, coupled with Intel ignoring it after being given years of notice and also the unease about AMT in the OSS community since it's deployment. To be honest, I doubt 9/10 people who care about this are going to stop using Intel, but it's still a comedy of errors and I think everyone loves a spectacle.
  - lima 9y ago
    > Intel ignoring it after being given years of notice Sure about that? From what I can tell, it's a recently discovered vulnerability that was promptly fixed.
    - DKnoll 9y ago
      According to SemiAccurate (terrible name for a source) they reported it to Intel some time ago.
      - lima 9y ago
        As far as I know, Embedi and not SemiAccurate found and reported the issue. https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf https://www.embedi.com/files/white-papers/Silent-Bob-is-Sile... > An authentication bypass vulnerability, which will be later known as CVE-2017-5689, was originally discovered in mid-February of 2017 while doing side-research on the internals of Intel ME firmware. The first objects of interest were network services and protocols.
lima 9y ago
I disagree with the article. If anything, it's much less severe than many people thought. - It's a logic bug (authentication bypass) instead of a memory corruption. An authentication bypass is bad, but a full compromise would have been much worse. - It's a bug in the opt-in AMT management, which means that the default config is not vulnerable.
- lightedman 9y ago
  "An authentication bypass is bad, but a full compromise would have been much worse." Given the authentication bypass essentially leads to full compromise, where's the difference, here?
  - dom0 9y ago
    The ME itself is not compromised. Arbitrary code execution on the ME would mean total control of the host, i.e. privileges above any software you can run on a computer.
    - kogepathic 9y ago
      > would mean total control of the host, i.e. privileges above any software you can run on a computer. You don't need arbitrary code execution, the ME already has privileges above any software you can run on the computer. The ME operates in ring -2 mode [0], whereas the OS kernel has at most ring 0 privileges. With the built-in ME functionality you can: reboot the host, change BIOS settings, re-install the OS, update BIOS (boot FreeDOS & run the vendor utility). Couple this with a vendor vulnerability such as not signing and verifying a BIOS before flashing, and you can easily use the ME to flash a BIOS with malicious components to the computer. So, yes, it's not as bad as using the ME to read arbitrary memory regions while the host is on, but the default ME functionality for remote management is still enough for a malicious actor to cause a lot of harm. [0] https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/System_Management_Mode
      - pritambaral 9y ago
ComodoHacker 9y ago
So where all this authentication and web UI code resides? Is it in the BIOS? Is there somewhere a packed JQuery or something?
- tyingq 9y ago
  It's in the AMT code, written in C, in the management engine processor...which is separate from the main processor. See: https://software.intel.com/en-us/node/631399 https://software.intel.com/en-us/node/631399 They are using HTTP Digest Authentication, which is built into browsers. The purpose was to keep passwords from being clear text over regular http connections. So, the code on the client side is in the browser. The code on the server side is in the management processor, and it is a C implementation of HTTP Digest Auth. The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. The exploit is to send an empty hash. That requires a proxy, or browser plugin, since the browser creates the Digest Auth Headers. The empty hash causes something like strncmp(expected, received_hash_string, 0), and of course, two zero length strings are equal.
  - jjnoakes 9y ago
    > The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. Ignoring timing attacks, they should have used strcmp(), not strncmp(). strncmp() is for testing if one string is a prefix of another; they wanted to test if some string equaled another. Since this is crypto related stuff, though, they should be using a strcmp()-like routine that works in a content-independent timing fashion.
    - adkafka 9y ago
      But using strcmp could result in buffer overflow, no?
      - jjnoakes 9y ago
ForFreedom 9y ago
Should be more like a backdoor that NSA/CIA can walk in rather than hijacking flaw or "OH! I didnt know there was a flaw!" Surely a new one must have been created since NSA tools are out on the net
dataminded 9y ago
This is a dream come true for AMD.
- Neliquat 9y ago
  AMD has a similar system, likely with simular issues. Their smaller footprint means they just take longer for people to notice than an Intel snafu. Hopefully this will give them a preemptive heads up to harden theirs before an exploit is discovered.
  - rocqua 9y ago
    AMD made some noise (way before this vulnerability became known) about open-sourcing the code of their ME-equivalent and allowing people to flash their own code. That seems a lot better than Intel's stance on the ME.
    - Unklejoe 9y ago
      Unless something new happened that I'm unaware of, it was more like "the people of Reddit made some noise in an AMA, and AMD basically said "we'll look in to it"".
tyingq 9y ago
There's two things that don't get mentioned much with this issue. 1. There's a second bug that allows non-root local users to provision AMT. "An unprivileged local attacker could provision manageability features"[1] 2. Access to AMT allows you to boot a recovery image, mount local drives, and do whatever you like with the included remote KVM.[2][3] So, even if this is turned off, there are issues to address. If it's on, they have control of the whole machine, remotely. It's as bad as it can get. [1] https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 https://security-center.intel.com/advisory.aspx?intelid=INTE... [2] https://software.intel.com/en-us/node/681803 https://software.intel.com/en-us/node/681803 [3] https://software.intel.com/en-us/node/674998 https://software.intel.com/en-us/node/674998
mjw1007 9y ago
One interesting note in the article: « unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware. » That's unsurprising now I think about it, given how AMT works, but aren't the sort of companies that would want to use AMT also the sort of companies that have security policies that require all such things to be logged?

208 points by podiki 9y ago

lisper 9y ago

It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.

benchaney 9y ago
Because if you are going to do security wrong, why not do it really really wrong.
megadollar 9y ago
That's fine. I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. Take your attack vector to be that particular md5sum that you are making fun of. MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security. In addition to the fundamental technical deficiency you've demonstrated, people who opine on security threads while not quite understanding anything about computer security allow charlatans to sell "computer security". Every single comment like this lends credence to literal scam artists. ¹note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)
- lightedman 9y ago
  "MD5 is not broken for the usage that you think it's broken for." Correct; it's broken for everything since we've got the computational power to make it essentially ineffective.
  - Xylakant 9y ago
    That's not entirely true. It's broken in the sense that for every hash given we can compute an input that produces this hash. Constructing a useful input (in this case a working exploit) is much less trivial. The complexity depends significantly on what the desired input should look like. It's easier for input that have the property that they can ignore chunks of the input (googles PDF example), but still hard for others.
    - megadollar 9y ago
      We cannot produce an input that produces an arbitrary given hash. Here's an easy counterexample: the all-zeroes md5sum. That's an even harder problem than the one I've claimed is entirely not solved. MD5 is still preimage and second-preimage resistant.
- technion 9y ago
  The other way to look at this is.. MD5 is known to be a poor option. And every few years the practicalities of attacking it increase. And when the type of attack described here does become practical, all we'll be hearing is one side saying "they had ten years to fix this" and another side saying "but experts we consulted said it was fine". It is incredibly easy for whatever process builds a website with an MD5 hash of a download to instead display something else, so the cost trade off becomes: Cost: Virtually nil Mitigation: Currently minimal but has future potential That a company would look at that and say "I guess we'll make a choice to stick with MD5" says something, even if it doesn't say the website downloads are easily compromised. Alternatively, the parent comment could be pointing out that no hash signature that only exists on the download site itself offers value, and they would be better served offering a GPG signature or similar.
- stevenh 9y ago
  Hello fellow ordinary person using an account created a year ago and finally posting today for the very first time with comically irrational outrage over the possibility of people ever moving away from md5sum thus rendering useless whatever subset of shady tools you or your employer has that we don't know about yet. Consider making innocuous comments in various threads for a few weeks before you switch to psyop mode next time.
  - coldtea 9y ago
    Tin foil much? As if what will ...really help NSA and co are 1-2 random comments of technical pedantry regarding MD5 on an insignificant (in the grand scheme of things) forum people go to discuss the latest startup news, JS frameworks, the benefits of functional programming, Golang, tech industry developments, and some CS related news.
    - chillingeffect 9y ago
      Sustained disinformation campaigns are a go-to strategy. Redirecting and confounding conversations are documented tactics. They don't even have to be particularly well veiled or surgically placed as their value derives from their volume.
- heinrich5991 9y ago
  There are easy collision attacks against MD5. If they used a stronger hash, we would know that they couldn't have been coerced to use a hash that collides with a bad version of the update.
- lisper 9y ago
  > I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. It's almost certainly a question of when, not if, I will be able to collect on that offer.
- benchaney 9y ago
  The reason that people move away from a hash function when it looses collision resistance is that collision resistance serves as a measure of the security margin for preimage resistance. Cryptographic primitives are intended to be rotated out of use about 10-15 years before they become actually broken for their intended purpose. Unless you are willing to extend you bounty to the year 2030 it is means nothing. In addition, you are completely wrong about the harm caused by simplifying the rules of thumb for security. There is not good reason to ever use MD5 for this purpose, and saying "MD5 is ok in some cases" has the potentially to do far more harm than "never use MD5". > note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!) Don't act like you are doing GP a favor, second preimage is the attack that would cause a vulnerability in this usage of MD5. You are the one who is"opin[ing] on security threads while not quite understanding anything", so I think before the next time you condescendingly correct someone you should make sure you have a basic understanding of what you are talking about.
  - megadollar 9y ago
    You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb and you've since argued against a strawman. Did I ever say "MD5 is ok in some cases"? Aside: a preimage attack implies a second preimage attack.
    - benchaney 9y ago
      >You're clearly somebody who wants to rely on "rules of thumb" for security. I'm arguing against the entire concept of rules of thumb Not all devs are security experts, or can even afford to focus on security. To deny the value of rules of thumb is to deny that they need to consider security. > Did I ever say "MD5 is ok in some cases"? Oh, really? Were you not arguing that MD5 is ok if you only need preimage resistance? > MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security. Hmm. Seems like you were...
nogbit 9y ago
It's because both colliding files have to be specially prepared by the attacker, before they are published on a download site or presented for signing by a code signing scheme. https://www.win.tue.nl/hashclash/SoftIntCodeSign/ https://www.win.tue.nl/hashclash/SoftIntCodeSign/ Which means, the published MD5 on on the Intel site would have to be the hash that the attacker created. Though I'm sure there are better methods that Intel could implement.

CodeWriter23 9y ago

Interesting how this article steadfastly refers to the subsystem as AMT and never mentions Management Engine/ME. A deliberate ploy to redirect people away from discovering all the ME-disabling research and tech? Perhaps. This is what happens when "journalists" post copypasta from publicists.

ars 9y ago
I quote: "When AMT is enabled, all network packets are redirected to the Intel Management Engine"
- jgaa 9y ago
  As far as I know, it's only doing this for the primary (on-chip) network interface. /Never/ use the primary NIC if you have a Intel CPU.
- lima 9y ago
  Which is wrong, by the way. What actually happens is that a filter is installed on the NIC that redirects some packets (those addressed to the ME).
khedoros1 9y ago
AMT's an optional component of the ME, it's the part that enables remote management, and it's a flaw in AMT that they're describing. It seems reasonable to talk about the part that has a problem (although it wouldn't have been unreasonable for them to mention that it's part of the IME, of course).
confounded 9y ago
From the article: > When AMT is enabled, all network packets are redirected to the Intel Management Engine and from there to the AMT. The packets bypass the OS completely. The vulnerable management features were made available in some but not all Intel chipsets starting in 2010, Embedi has said. The vulnerability is in AMT, not ME (though I agree that the ME is an unnecessary security risk, and am well behind the current research to disable it).

Cyph0n 9y ago

There is a great comment linked at the bottom of the article that explains what exactly caused the authentication bug (it was strncmp!). Is there somehow a law that states that the higher the severity of a software bug, the simpler the reason behind it?

mirimir 9y ago
Yes, that is crazy. Checking for match based on the length of the input. If input is "", that matches anything.
chmaynard 9y ago
From the comment: 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...
- benchaney 9y ago
  strcmp has its own issues. What they actually should have done is use a cryptography library with properly implemented comparison, because it is surprisingly easy to get wrong. Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings. Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is deprecated and should not be used for new projects.
  - dom0 9y ago
    Yep, even if they had used memcmp/strncmp correctly the AMT would still be vulnerable to a timing attack here, which is probably even easy, because it runs on a low-power system with, I assume, not much background activity.
    - benchaney 9y ago
      In addition to timing attacks, if the attacker supplied a non null terminated string, it could potentially cause a memory overrun. This may not be possible depending on how the string is handled on ingress, but if it is, it would likely have serious consequences.

benchaney 9y ago

I wish that this security incident would get more attention. It seems fundamentally unfair that some projects that are essentially volunteer labor get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets mostly ignored.

rfugger 9y ago
Being an advertiser has its privileges.
DKnoll 9y ago
If scrutiny improves the project it's ultimately a good thing.
- d33 9y ago
  ...which is exactly why Intel chips should get it too.
  - DKnoll 9y ago
    Totally, but what I'm saying is it's not unfair, it's an inherent benefit of OSS.

geofft 9y ago

At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function. If you want to fix this, there's no strict need to move away from C (not that I'd particularly encourage you to stay, but if you have some reason to prefer C, you can solve this in C). There are a number of C libraries that give you a struct string {char *ptr; int len;} of some sort, from bstring to GLib. And there's always C++, too. What need does the Intel AMT firmware have for compatibility with POSIX string APIs? It's not running a POSIX OS, is it?

code_sloth 9y ago
Could you elaborate on why "treating the pointer to a string and the string length as separate vars" is dangerous to someone who hasn't done a lot of C?
- pabl0rg 9y ago
  If you access a memory location beyond the end of the string, you can get all sorts of unexpected behavior. The string's length is something you'll pretty much always need to take into account.
  - DaiPlusPlus 9y ago
    Many libraries and systems (e.g. Win32) just go with null-terminated strings and their functions don't accept a length argument at all - so I wonder if some people never store the length simply because they don't believe they'll ever need it.
- qb45 9y ago
  Because occasionally you use wrong length with wrong pointer and read or overwrite something you didn't want to. It's more convenient and safer to have these two variables packed together as a "string object" and have string functions operate on that - then they always know where the string starts and ends in memory.

Myrmornis 9y ago

Is the amount of attention this is getting commensurate with how interesting/surprising/consequential a security flaw it is?

gpvos 9y ago
No, it looks like it's not getting enough attention. (Well, OK, it is not terribly surprising.)
DKnoll 9y ago
I don't think it's just that the flaw exists, which alone is pretty bad, but how widely deployed it is in large enterprise, coupled with Intel ignoring it after being given years of notice and also the unease about AMT in the OSS community since it's deployment. To be honest, I doubt 9/10 people who care about this are going to stop using Intel, but it's still a comedy of errors and I think everyone loves a spectacle.
- lima 9y ago
  > Intel ignoring it after being given years of notice Sure about that? From what I can tell, it's a recently discovered vulnerability that was promptly fixed.
  - DKnoll 9y ago
    According to SemiAccurate (terrible name for a source) they reported it to Intel some time ago.
    - lima 9y ago
      As far as I know, Embedi and not SemiAccurate found and reported the issue. https://www.embedi.com/files/white-papers/Silent-Bob-is-Silent.pdf https://www.embedi.com/files/white-papers/Silent-Bob-is-Sile... > An authentication bypass vulnerability, which will be later known as CVE-2017-5689, was originally discovered in mid-February of 2017 while doing side-research on the internals of Intel ME firmware. The first objects of interest were network services and protocols.

lima 9y ago

I disagree with the article. If anything, it's much less severe than many people thought. - It's a logic bug (authentication bypass) instead of a memory corruption. An authentication bypass is bad, but a full compromise would have been much worse. - It's a bug in the opt-in AMT management, which means that the default config is not vulnerable.

lightedman 9y ago
"An authentication bypass is bad, but a full compromise would have been much worse." Given the authentication bypass essentially leads to full compromise, where's the difference, here?
- dom0 9y ago
  The ME itself is not compromised. Arbitrary code execution on the ME would mean total control of the host, i.e. privileges above any software you can run on a computer.
  - kogepathic 9y ago
    > would mean total control of the host, i.e. privileges above any software you can run on a computer. You don't need arbitrary code execution, the ME already has privileges above any software you can run on the computer. The ME operates in ring -2 mode [0], whereas the OS kernel has at most ring 0 privileges. With the built-in ME functionality you can: reboot the host, change BIOS settings, re-install the OS, update BIOS (boot FreeDOS & run the vendor utility). Couple this with a vendor vulnerability such as not signing and verifying a BIOS before flashing, and you can easily use the ME to flash a BIOS with malicious components to the computer. So, yes, it's not as bad as using the ME to read arbitrary memory regions while the host is on, but the default ME functionality for remote management is still enough for a malicious actor to cause a lot of harm. [0] https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/System_Management_Mode
    - pritambaral 9y ago

ComodoHacker 9y ago

So where all this authentication and web UI code resides? Is it in the BIOS? Is there somewhere a packed JQuery or something?

tyingq 9y ago
It's in the AMT code, written in C, in the management engine processor...which is separate from the main processor. See: https://software.intel.com/en-us/node/631399 https://software.intel.com/en-us/node/631399 They are using HTTP Digest Authentication, which is built into browsers. The purpose was to keep passwords from being clear text over regular http connections. So, the code on the client side is in the browser. The code on the server side is in the management processor, and it is a C implementation of HTTP Digest Auth. The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. The exploit is to send an empty hash. That requires a proxy, or browser plugin, since the browser creates the Digest Auth Headers. The empty hash causes something like strncmp(expected, received_hash_string, 0), and of course, two zero length strings are equal.
- jjnoakes 9y ago
  > The bug is that they used strncmp, but used the length of the incoming hash from the client as the string length to compare, versus the actual length that the hash string is supposed to be. Ignoring timing attacks, they should have used strcmp(), not strncmp(). strncmp() is for testing if one string is a prefix of another; they wanted to test if some string equaled another. Since this is crypto related stuff, though, they should be using a strcmp()-like routine that works in a content-independent timing fashion.
  - adkafka 9y ago
    But using strcmp could result in buffer overflow, no?
    - jjnoakes 9y ago

ForFreedom 9y ago

Should be more like a backdoor that NSA/CIA can walk in rather than hijacking flaw or "OH! I didnt know there was a flaw!" Surely a new one must have been created since NSA tools are out on the net

dataminded 9y ago

This is a dream come true for AMD.

Neliquat 9y ago
AMD has a similar system, likely with simular issues. Their smaller footprint means they just take longer for people to notice than an Intel snafu. Hopefully this will give them a preemptive heads up to harden theirs before an exploit is discovered.
- rocqua 9y ago
  AMD made some noise (way before this vulnerability became known) about open-sourcing the code of their ME-equivalent and allowing people to flash their own code. That seems a lot better than Intel's stance on the ME.
  - Unklejoe 9y ago
    Unless something new happened that I'm unaware of, it was more like "the people of Reddit made some noise in an AMA, and AMD basically said "we'll look in to it"".

tyingq 9y ago

There's two things that don't get mentioned much with this issue. 1. There's a second bug that allows non-root local users to provision AMT. "An unprivileged local attacker could provision manageability features"[1] 2. Access to AMT allows you to boot a recovery image, mount local drives, and do whatever you like with the included remote KVM.[2][3] So, even if this is turned off, there are issues to address. If it's on, they have control of the whole machine, remotely. It's as bad as it can get. [1] https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 https://security-center.intel.com/advisory.aspx?intelid=INTE... [2] https://software.intel.com/en-us/node/681803 https://software.intel.com/en-us/node/681803 [3] https://software.intel.com/en-us/node/674998 https://software.intel.com/en-us/node/674998

mjw1007 9y ago

One interesting note in the article: « unauthorized accesses typically aren't logged by the PC because AMT has direct access to the computer's network hardware. » That's unsurprising now I think about it, given how AMT works, but aren't the sort of companies that would want to use AMT also the sort of companies that have security policies that require all such things to be logged?