9 ms·

Rediscovering the Intel AMT Vulnerability

133 points by xorrbit 9y ago

RichardHeart 9y ago
Will blocking ports 16992 and 16993 at router block this attack (as those are the AMT ports.)?
denois 9y ago
Intel is such an evil company: 1. They are stealing customers data and secretly sending it to their HQ and to NSA 2. They do financially support feminism movements (why I should pay for this?) 3. Abused their monopoly status and sold processors for MUCH higher prices. 4. Reduced investments to CPU research to increase margins. etc... My next CPU will be from AMD.
DuskStar 9y ago
So the AMT vuln was related to a lack of security on their web service? Somehow this does not increase my confidence in the rest of their code - if they didn't get this right, what else is wrong?
- fhood 9y ago
  To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.
  - Karunamon 9y ago
    That's more of an argument about inauditable, non-disableable, hostile (the CPU shuts itself off if you blank out the appropriate data structures) code running below ring 0
    - throwaway2048 9y ago
      Don't forget in the majority of cases unupdatable too! (No vendor is going to issue fixes for old boards)
- FrozenVoid 9y ago
  see https://threatpost.com/researcher-baseless-assumptions-exist-about-intel-amt-vulnerability/125390/ https://threatpost.com/researcher-baseless-assumptions-exist...
- tyingq 9y ago
  The Intel note mentioned a local vulnerability that allowed local non root users to provision AMT as well. That sounds like at least one more, different, issue.
MichaelGG 9y ago
So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box? Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?
- semi-extrinsic 9y ago
  I also understand AMT is only found on vPro branded CPUs, which most consumers don't buy. You can search here to get a list; e.g. select {vPro: yes, Embedded graphics: yes} to see "normal" CPUs that are affected. http://ark.intel.com/Search/Advanced http://ark.intel.com/Search/Advanced
- bobsam 9y ago
  Many enterprise users are affected by this.
  - MichaelGG 9y ago
    Sure but they'd be affected regardless, due to enabling a remote management system. All I'm asking is if there's any real damage because this is built in by Intel. If Intel didn't ship this, then OEMs would, just like e.g. Dell DRAC, right? And that'd have the same attack surface.
    - AnimalMuppet 9y ago
      But, IIUC, this has more power once exploited.
    - Crespyl 9y ago
      I'm not familiar with DRAC, but if it's something added by an OEM wouldn't it have to be in the UEFI/BIOS layer or higher? AMT/ME and its ilk are a physical coprocessor built into the CPU, whether it's "enabled" or not, not something that can be added or removed after the fact.
    - 9y ago
qb45 9y ago
TL;DR: memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len) Hey, at least they didn't read past the submitted buffer. edit: Note that this is only pseudocode and rumor has it that ME firmware is actually written mostly in Java. It's not immediately clear to me how to create equivalent bug in Java, the obvious string.equals() method doesn't ignore length mismatch. edit2: s/passwd/passwd_hash to satisfy pedants below ;)
- kevindqc 9y ago
  No. That was another vulnerability used as an example. In this case, if you don't send some hash, it will authenticate you, allowing you to authenticate with user `admin` and no password.
  - terom 9y ago
    The article discusses an actual partial prefix match. > we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded! > Next, we reduced the response hash to one hex digit and authentication still worked. This doesn't imply that "no password" - an empty password would still result in a non-empty HTTP Authorization Digest response hash, which would not allow you to login. An empty/truncated digest response hash is not the same thing as an empty/truncated password.
- jfoutz 9y ago
  Quite a bit of Java memory safety comes from the JVM. Array bounds checking, for example. If they're embedding an entire oracle JVM then it's probably pretty safe. On the other hand, if they're compiling down to a home made vm with a home made compiler, well. who knows? Dalvik did that and it had some problems. It seems really hard to test from the point of an outside observer. I'd strongly suspect it's hard to test internally as well, which would indicate there are a bunch of bugs lurking in there.
  - justinclift 9y ago
    > If they're embedding an entire oracle JVM then it's probably pretty safe. This sounds a bit strange to me. Oracle releases a lot of updates for the JRE. eg Java 8 is up to number 131 at the time of writing this, though they're probably (hopefully!) not all security updates: • http://www.oracle.com/technetwork/java/javase/downloads/index.html http://www.oracle.com/technetwork/java/javase/downloads/inde... • http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html http://www.oracle.com/technetwork/java/javase/8u-relnotes-22... With that in mind, wouldn't an embedded Oracle JVM be a very bad idea from a security standpoint? (if network connected, and not updated of course)
bobsam 9y ago
Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching. That's the problem you should discuss, not this particular exploit.
- nullc 9y ago
  So has AMD.
  - djsumdog 9y ago
    ..and HP servers/sans (iLO)
    - Godel_unicode 9y ago
      That's a separate system which lives on a daughter board. It's essentially a kvm+usb cdrom+power switch. No disk access, no dma. Not the same thing at all. Edit: and trivially removable if you don't want it.
      - mjg59 9y ago
        > No disk access AMT doesn't provide raw disk access either > no dma It's connected to PCI. What makes you so sure that it has no DMA access? > Not the same thing at all Indeed - iLo is pretty good, but the implementations provided by other vendors have an even worse track record than AMT does.
        yuhong 9y ago
        I think they even excluded iLO when they locked down firmware updates to paid customers just after https://lkml.org/lkml/2013/11/11/653 https://lkml.org/lkml/2013/11/11/653 (they are the one who ported UEFI to RISC-V too!)
    - dom0 9y ago
      Well if you want to walk to the DC every time a server throws a tantrum, be my guest.
deleted 9y ago
[deleted]
logicallee 9y ago
[withdrawn]
- SomeStupidPoint 9y ago
  I'm not sure what you're trying to say -- we can't discuss IME being a second computing system inside of your computer controlled by someome else? Because I seem to have just done that. We can even talk about why the existence of that system is problematic, since it gives someone else control over "your" computer.
  - logicallee 9y ago
    [withdrawn]
    - SomeStupidPoint 9y ago
      Are you just trolling? I've read literally dozens about how Intel ME is a potential vector and it's problematic to have, particularly when unneeded on consumer devices (a number of them here on HN). There's whole discussions about it from people like Libreboot and others who work on fully open systems. Every security professional I've worked with has been aware that there's a potential hardware level backdoor you can't wipe out the firmware for without bricking your machine, and has opinions about it. I typed "Intel management engine second computer" in to Google, and found articles calling it a privacy/security threat and potential backdoor ranging back to 2010/2011 timeframe on the first page of results. (That's not even a good phrase to search with to find info, I just wanted to prove the point that you can find pieces with literally the first thing that comes to mind.)
      - Spooky23 9y ago
        Did you find an exploit that impacted consumers?
      - rayiner 9y ago
        It seems super useful to me. It lets you do OS installs without a keyboard/screen using VNC. Note that stuff like IPMI is standard in the server world.
kbenson 9y ago
Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header). Authentication still worked. We had discovered a complete bypass of the authentication scheme. What. the. fuck. This is not the kind of bug you should ship in anything if you have the barest bit of testing in place, much less a large company like Intel, in an enterprise feature which has a lot of security ramifications, and which has apparently existed for a long time (years?). Edit: Also, this is really good evidence for short and hard disclosure deadlines. What's the chance something as simple as this wasn't known by someone else? All they had to do was decide to look and they found something within minutes. It's not like this is obscure or doesn't get your much, it's about as juicy as they come.
- mdip 9y ago
  Wow. Just Wow. After reading about this over several days I would have never guessed it was such a gaping hole. This reminds me of a software bug I encountered in the 90s with a version of the Renegade BBS software (a Telegard hack). In one minor revision, you could login to any account by just not bothering to enter a password. Though the "sysop" (admin) account often had a custom name, for convenience, you could login by your user number and the sysop user number was always zero. A good friend of mine had his entire system wiped out by a malicious user with this little problem. It doesn't sound like this is a matter of leaving the password field blank, but rather sending a request with a tool like cURL and setting the header to an empty/NULL response, but it's about as close to just as bad as you can get. Sheesh.
  - mirimir 9y ago
    So what might the coding error have been? I mean, it seems like null password matches any password. Parsing null can be hard, but seriously?
    - mdip 9y ago
      In the case of Intel's AMT, I'm not sure what could have possibly gone wrong, but it sounds like this is something that has happened in other applications that use Digest Authentication. In the case of Renegade's BBS software, I don't exactly recall the specifics and since it's been several years, I may not have this exactly right but I'm fairly certain this is how it happened because I did a lot of work with the code it was based on[0]. The bug occurred only if the user didn't provide a password. So, effectively, you could login by not providing a password or by providing the correct password. In the original Telegard source, the login prompt did nothing if no password was provided, it simply discarded the provided Enter and waited for a password. This was handled by a global function that was used for accepting input. I'm guessing that function was refactored (I ended up doing this ... it was pretty ugly IIRC) in the Renegade code and it became possible to send a blank password. The login routine was an interesting beast, as well. I remember reviewing it in the original code and scratching my head ... it made positively no sense and so I threw it out and replaced it with a much simpler implementation. Rumors had swirled around the release of the source code that this obfuscation was intentional and that there was a back-door built into the login routine. I'm not sure if that's true or not but the sheer amount of code to do a string comparison was a little ridiculous[1] -- passwords were not hashed, they were stored in plain text in a record (struct-like component) dumped to a file and were even viewable in the sysop control panel's User Editor. It's entirely possible that they didn't refactor this bit of logic but changed something in that mess that caused an empty string to evaluate true along with a matched string. Or it could be that they refactored that like I did and put an OR where an AND belonged. If they refactored that global ReadLine method to allow empty returns, they may have felt a need to check for an empty value at this prompt, though I'm not sure what the motivation for this would have been. An empty or NIL value wouldn't have caused the application to crash -- there's no null reference exceptions when you're dealing in a non-OOP language -- you're not executing methods attached to the String type because such a thing didn't exist in the language. The developer should have discovered the problem way before it was ever released in the wild, but I get why it was missed. He probably checked a bad value and a good value but never thought to check no value at all. Hell, it was a mystery why all of these Renegade boards were going down and a bunch of folks assumed it was a back-door, as was suspected about the original Telegard code. It was a few weeks before people figured out that it was such a simple screw-up. [0] The source code wasn't public, it wasn't open source. In fact, it only existed because an older version of Telegard had its source code leaked, which the Renegade developers used to create their product (there were a number of "Telegard Hacks" in those days, including one I wrote and later rewrote from scratch and served as the entire reason I decided to become a software developer). [1] Sounds suspicious at first glance but there were so many really poorly performing things about Borland Pascal's core libraries that it was not uncommon to write several hundred lines of inline assembly to do things like "write text to the screen quickly". I had done this, myself, on a few occasions -- the specifics were something around writing to memory reserved for use by the display capabilities of the 8088/80286/80386 (BIOS reserved memory IIRC). [2] NIL was Borland Pascal's "null", and I believe it supported empty strings. Unlike ISO PASCAL at that time, Borland Pascal had a real string type which was stored in memory as a character array with a length field at the 0th index. It didn't use null terminated character arrays like C/C++ which made working with strings in the language elegant by comparison. Strings, however, were 8-bit ASCII ... this being the 90s with the target being DOS and all.
walterbell 9y ago
If AMT provides remote management of devices that are turned off, what program provides authentication of remote management requests when the OS is powered off? Has that interface been audited for authentication vulnerabilities? If there is an OS-independent, network-accessible AMT management service, when would an admin need to switch from that service to the Windows-hosted web interface? Why can't all AMT operations be performed without an OS?
- mjg59 9y ago
  There is no Windows-hosted web interface, the web interface is provided by AMT. LMS is for accessing AMT from the local machine (AMT is listening to the network hardware, so trying to connect to the web UI locally won't work - the OS will shortcut the network hardware)
thyrsus 9y ago
The article says that a Local Management Service (LMS) must be installed for the bug to be demonstrated[0], and describes a Windows package that provides that. Is there a Linux equivalent? [0] I say "demonstrated" instead of "exploited", since I don't understand the details sufficiently to rule out exploitation in the absence of LMS.
- anoother 9y ago
  Yes, there is. I haven't looked into the exploit, but if the attack uses AMT's http(s) interface, you could also simply access the AMT port(s) from a remote machine. The service simply allows one to speak to the local ME.
xgen 9y ago
AMD have something similar to this, and there was some mentioning of this in an ama on reddit here: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/ https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea... What are the reasons for having this, I mean good business reasons? I get that designing cpus is expensive and they reuse as much they can, and that businesses would want the benefits or remote management. However when weighed up against the damage to trust in a company is it worth it enough that they do not offer a line of chips that do not have this pseudo back door present?
- wmf 9y ago
  Most Intel PCs do not have AMT firmware and thus aren't affected by any AMT firmware vulnerabilities.
  - xgen 9y ago
    Is management engine not on all modern intel chips, but comes disabled requiring it to be set up in the BIOS?
    - wmf 9y ago
      The ME is on all chips but the ME doesn't provide remote management. You're confusing two different things.
- mdip 9y ago
  > What are the reasons for having this, I mean good business reasons? So, I'll avoid writing anything about NSA collusion or related speculation and talk specifically about what you've asked -- business reasons. The main reason is that customers are already purchasing technology like this through third-party expansion cards and this kind of technology makes those (expensive) adapters less necessary for those customers if its built into the CPU. At a past company I worked at, every HP Proliant server we purchased was purchased with a PCI Express adapter that was a full computer on a card. It came with a special cable that passed the 15-pin VGA output through the card and allowed complete control of the server (and we purchased the "Lights Out" edition which included battery power so that the server could be powered on remotely). It allows one to do things you can't do through software remote management, like install the operating system, modify the BIOS settings, see POST messages at boot. It sounds like AMT offers a lot of this functionality without the need for that (I think $700) board, which would be appealing to a lot of enterprises, almost all of whom consider folks screaming about possible vulnerabilities in AMT as tin-foil-hat wearing security geeks, or have otherwise convinced themselves that "it'll never happen to me (or Intel, etc)". I, personally, tried in vein to point out the security threats that these third-party boards posed to the organization, being that the software could not be audited, was often used for years past the support date of the hardware (where security patching via firmware updates was no longer provided) and allowed complete and total access to the system in ways that even the worst OS vulnerability wouldn't (that was the point, after all), but was basically told that the benefits outweighed the risks[0]. The argument for using a management board, however, was a little easier to make than the argument for using AMT. Our security standards required that any device with a management interface be segregated to a high-security management network that, while not air-gapped, was protected via additional VPN and two-factor authentication and no access to the internet from within. It's unhelpful if the laptop of the administrator with the appropriate token is infected with something, but at least this allowed for one extra set of firewalls between those interfaces and the internet. Now...whether or not these boards were actually on said management network is anyone's guess and in the case of AMT-style software, there'd be no way to do something similar. These PCI-e boards were complete computers with their own isolated[0] network adapters. [0] I'm not positive about this one and in all likelihood a sufficiently bad vulnerability might make that separation irrelevant, but AFAIK, the network adapters on these boards were not accessible to the OS and were used by the management interface, only. If that wasn't the case, that would have made a great argument for their elimination since the management network would then be accessible via corporate (which is what the server was plugged into) without the VPN connection.
cmurf 9y ago
FTA: "the discovery of a possible zero-day in widely distributed firmware" Is this CPU firmware? Or microcode? Or is it logic board firmware (UEFI base)? And if it's CPU firmware, is that replaceable or is it permanently baked into the CPU?
orblivion 9y ago
So does this cut down the attack to people on your network? Would a simple NAT protect me here? Also it's bizarre that they're disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don't read hacker news and who aren't exactly going to update their BIOS as an everyday thing.
- MichaelGG 9y ago
  This feature is only active if you set it up and configure it for your company/management system. Random Lenovo customers aren't at risk. The only people at risk are companies that set AMT up, and then they should be looking for security issues with all the vendors they use.
- roywiggins 9y ago
  If you're not a business customer you won't have AMT provisioned, so this hack won't work remotely. Apparently a local attacker could provision AMT and then perform the attack, but that's substantially less bad.
microcolonel 9y ago
Closed source custom Java ME and ThreadX blob probably maintained by interns, running all the time with unfettered access to every resource in the system even when the machine is turned off, integrated into almost every enterprise computer network in the world. What could possibly go wrong.

133 points by xorrbit 9y ago

Will blocking ports 16992 and 16993 at router block this attack (as those are the AMT ports.)?

Intel is such an evil company: 1. They are stealing customers data and secretly sending it to their HQ and to NSA 2. They do financially support feminism movements (why I should pay for this?) 3. Abused their monopoly status and sold processors for MUCH higher prices. 4. Reduced investments to CPU research to increase margins. etc... My next CPU will be from AMD.

DuskStar 9y ago

So the AMT vuln was related to a lack of security on their web service? Somehow this does not increase my confidence in the rest of their code - if they didn't get this right, what else is wrong?

fhood 9y ago
To be fair, it is pretty rare (impossible) to find "secure" software that has zero avoidable vulnerabilities.
- Karunamon 9y ago
  That's more of an argument about inauditable, non-disableable, hostile (the CPU shuts itself off if you blank out the appropriate data structures) code running below ring 0
  - throwaway2048 9y ago
    Don't forget in the majority of cases unupdatable too! (No vendor is going to issue fixes for old boards)
FrozenVoid 9y ago
see https://threatpost.com/researcher-baseless-assumptions-exist-about-intel-amt-vulnerability/125390/ https://threatpost.com/researcher-baseless-assumptions-exist...
tyingq 9y ago
The Intel note mentioned a local vulnerability that allowed local non root users to provision AMT as well. That sounds like at least one more, different, issue.

MichaelGG 9y ago

So now that there's more info out, this is only a threat if you have remote management provisioned? And to provision it, you first need code execution on the box? Is the impact of this bug basically nothing to most users? And to provisioned users, it's just as bad as any bug on a remote management system? That is, the fact it's built in to the CPU makes no difference?

semi-extrinsic 9y ago
I also understand AMT is only found on vPro branded CPUs, which most consumers don't buy. You can search here to get a list; e.g. select {vPro: yes, Embedded graphics: yes} to see "normal" CPUs that are affected. http://ark.intel.com/Search/Advanced http://ark.intel.com/Search/Advanced
bobsam 9y ago
Many enterprise users are affected by this.
- MichaelGG 9y ago
  Sure but they'd be affected regardless, due to enabling a remote management system. All I'm asking is if there's any real damage because this is built in by Intel. If Intel didn't ship this, then OEMs would, just like e.g. Dell DRAC, right? And that'd have the same attack surface.
  - AnimalMuppet 9y ago
    But, IIUC, this has more power once exploited.
  - Crespyl 9y ago
    I'm not familiar with DRAC, but if it's something added by an OEM wouldn't it have to be in the UEFI/BIOS layer or higher? AMT/ME and its ilk are a physical coprocessor built into the CPU, whether it's "enabled" or not, not something that can be added or removed after the fact.
  - 9y ago

qb45 9y ago

TL;DR: memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len) Hey, at least they didn't read past the submitted buffer. edit: Note that this is only pseudocode and rumor has it that ME firmware is actually written mostly in Java. It's not immediately clear to me how to create equivalent bug in Java, the obvious string.equals() method doesn't ignore length mismatch. edit2: s/passwd/passwd_hash to satisfy pedants below ;)

kevindqc 9y ago
No. That was another vulnerability used as an example. In this case, if you don't send some hash, it will authenticate you, allowing you to authenticate with user `admin` and no password.
- terom 9y ago
  The article discusses an actual partial prefix match. > we tested out a case in which only a portion of the correct response hash is sent to the AMT web server. To our surprise, authentication succeeded! > Next, we reduced the response hash to one hex digit and authentication still worked. This doesn't imply that "no password" - an empty password would still result in a non-empty HTTP Authorization Digest response hash, which would not allow you to login. An empty/truncated digest response hash is not the same thing as an empty/truncated password.
jfoutz 9y ago
Quite a bit of Java memory safety comes from the JVM. Array bounds checking, for example. If they're embedding an entire oracle JVM then it's probably pretty safe. On the other hand, if they're compiling down to a home made vm with a home made compiler, well. who knows? Dalvik did that and it had some problems. It seems really hard to test from the point of an outside observer. I'd strongly suspect it's hard to test internally as well, which would indicate there are a bunch of bugs lurking in there.
- justinclift 9y ago
  > If they're embedding an entire oracle JVM then it's probably pretty safe. This sounds a bit strange to me. Oracle releases a lot of updates for the JRE. eg Java 8 is up to number 131 at the time of writing this, though they're probably (hopefully!) not all security updates: • http://www.oracle.com/technetwork/java/javase/downloads/index.html http://www.oracle.com/technetwork/java/javase/downloads/inde... • http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html http://www.oracle.com/technetwork/java/javase/8u-relnotes-22... With that in mind, wouldn't an embedded Oracle JVM be a very bad idea from a security standpoint? (if network connected, and not updated of course)

bobsam 9y ago

Intel decided they have the right to put a whole secret computer inside your computer that only they can access. God knows what it does when no one is watching. That's the problem you should discuss, not this particular exploit.

nullc 9y ago
So has AMD.
- djsumdog 9y ago
  ..and HP servers/sans (iLO)
  - Godel_unicode 9y ago
    That's a separate system which lives on a daughter board. It's essentially a kvm+usb cdrom+power switch. No disk access, no dma. Not the same thing at all. Edit: and trivially removable if you don't want it.
    - mjg59 9y ago
      > No disk access AMT doesn't provide raw disk access either > no dma It's connected to PCI. What makes you so sure that it has no DMA access? > Not the same thing at all Indeed - iLo is pretty good, but the implementations provided by other vendors have an even worse track record than AMT does.
      - yuhong 9y ago
        I think they even excluded iLO when they locked down firmware updates to paid customers just after https://lkml.org/lkml/2013/11/11/653 https://lkml.org/lkml/2013/11/11/653 (they are the one who ported UEFI to RISC-V too!)
  - dom0 9y ago
    Well if you want to walk to the DC every time a server throws a tantrum, be my guest.

deleted 9y ago

[deleted]

logicallee 9y ago

[withdrawn]

SomeStupidPoint 9y ago
I'm not sure what you're trying to say -- we can't discuss IME being a second computing system inside of your computer controlled by someome else? Because I seem to have just done that. We can even talk about why the existence of that system is problematic, since it gives someone else control over "your" computer.
- logicallee 9y ago
  [withdrawn]
  - SomeStupidPoint 9y ago
    Are you just trolling? I've read literally dozens about how Intel ME is a potential vector and it's problematic to have, particularly when unneeded on consumer devices (a number of them here on HN). There's whole discussions about it from people like Libreboot and others who work on fully open systems. Every security professional I've worked with has been aware that there's a potential hardware level backdoor you can't wipe out the firmware for without bricking your machine, and has opinions about it. I typed "Intel management engine second computer" in to Google, and found articles calling it a privacy/security threat and potential backdoor ranging back to 2010/2011 timeframe on the first page of results. (That's not even a good phrase to search with to find info, I just wanted to prove the point that you can find pieces with literally the first thing that comes to mind.)
    - Spooky23 9y ago
      Did you find an exploit that impacted consumers?
    - rayiner 9y ago
      It seems super useful to me. It lets you do OS installs without a keyboard/screen using VNC. Note that stuff like IPMI is standard in the server world.

kbenson 9y ago

Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header). Authentication still worked. We had discovered a complete bypass of the authentication scheme. What. the. fuck. This is not the kind of bug you should ship in anything if you have the barest bit of testing in place, much less a large company like Intel, in an enterprise feature which has a lot of security ramifications, and which has apparently existed for a long time (years?). Edit: Also, this is really good evidence for short and hard disclosure deadlines. What's the chance something as simple as this wasn't known by someone else? All they had to do was decide to look and they found something within minutes. It's not like this is obscure or doesn't get your much, it's about as juicy as they come.

mdip 9y ago
Wow. Just Wow. After reading about this over several days I would have never guessed it was such a gaping hole. This reminds me of a software bug I encountered in the 90s with a version of the Renegade BBS software (a Telegard hack). In one minor revision, you could login to any account by just not bothering to enter a password. Though the "sysop" (admin) account often had a custom name, for convenience, you could login by your user number and the sysop user number was always zero. A good friend of mine had his entire system wiped out by a malicious user with this little problem. It doesn't sound like this is a matter of leaving the password field blank, but rather sending a request with a tool like cURL and setting the header to an empty/NULL response, but it's about as close to just as bad as you can get. Sheesh.
- mirimir 9y ago
  So what might the coding error have been? I mean, it seems like null password matches any password. Parsing null can be hard, but seriously?
  - mdip 9y ago
    In the case of Intel's AMT, I'm not sure what could have possibly gone wrong, but it sounds like this is something that has happened in other applications that use Digest Authentication. In the case of Renegade's BBS software, I don't exactly recall the specifics and since it's been several years, I may not have this exactly right but I'm fairly certain this is how it happened because I did a lot of work with the code it was based on[0]. The bug occurred only if the user didn't provide a password. So, effectively, you could login by not providing a password or by providing the correct password. In the original Telegard source, the login prompt did nothing if no password was provided, it simply discarded the provided Enter and waited for a password. This was handled by a global function that was used for accepting input. I'm guessing that function was refactored (I ended up doing this ... it was pretty ugly IIRC) in the Renegade code and it became possible to send a blank password. The login routine was an interesting beast, as well. I remember reviewing it in the original code and scratching my head ... it made positively no sense and so I threw it out and replaced it with a much simpler implementation. Rumors had swirled around the release of the source code that this obfuscation was intentional and that there was a back-door built into the login routine. I'm not sure if that's true or not but the sheer amount of code to do a string comparison was a little ridiculous[1] -- passwords were not hashed, they were stored in plain text in a record (struct-like component) dumped to a file and were even viewable in the sysop control panel's User Editor. It's entirely possible that they didn't refactor this bit of logic but changed something in that mess that caused an empty string to evaluate true along with a matched string. Or it could be that they refactored that like I did and put an OR where an AND belonged. If they refactored that global ReadLine method to allow empty returns, they may have felt a need to check for an empty value at this prompt, though I'm not sure what the motivation for this would have been. An empty or NIL value wouldn't have caused the application to crash -- there's no null reference exceptions when you're dealing in a non-OOP language -- you're not executing methods attached to the String type because such a thing didn't exist in the language. The developer should have discovered the problem way before it was ever released in the wild, but I get why it was missed. He probably checked a bad value and a good value but never thought to check no value at all. Hell, it was a mystery why all of these Renegade boards were going down and a bunch of folks assumed it was a back-door, as was suspected about the original Telegard code. It was a few weeks before people figured out that it was such a simple screw-up. [0] The source code wasn't public, it wasn't open source. In fact, it only existed because an older version of Telegard had its source code leaked, which the Renegade developers used to create their product (there were a number of "Telegard Hacks" in those days, including one I wrote and later rewrote from scratch and served as the entire reason I decided to become a software developer). [1] Sounds suspicious at first glance but there were so many really poorly performing things about Borland Pascal's core libraries that it was not uncommon to write several hundred lines of inline assembly to do things like "write text to the screen quickly". I had done this, myself, on a few occasions -- the specifics were something around writing to memory reserved for use by the display capabilities of the 8088/80286/80386 (BIOS reserved memory IIRC). [2] NIL was Borland Pascal's "null", and I believe it supported empty strings. Unlike ISO PASCAL at that time, Borland Pascal had a real string type which was stored in memory as a character array with a length field at the 0th index. It didn't use null terminated character arrays like C/C++ which made working with strings in the language elegant by comparison. Strings, however, were 8-bit ASCII ... this being the 90s with the target being DOS and all.

walterbell 9y ago

If AMT provides remote management of devices that are turned off, what program provides authentication of remote management requests when the OS is powered off? Has that interface been audited for authentication vulnerabilities? If there is an OS-independent, network-accessible AMT management service, when would an admin need to switch from that service to the Windows-hosted web interface? Why can't all AMT operations be performed without an OS?

mjg59 9y ago
There is no Windows-hosted web interface, the web interface is provided by AMT. LMS is for accessing AMT from the local machine (AMT is listening to the network hardware, so trying to connect to the web UI locally won't work - the OS will shortcut the network hardware)

thyrsus 9y ago

The article says that a Local Management Service (LMS) must be installed for the bug to be demonstrated[0], and describes a Windows package that provides that. Is there a Linux equivalent? [0] I say "demonstrated" instead of "exploited", since I don't understand the details sufficiently to rule out exploitation in the absence of LMS.

anoother 9y ago
Yes, there is. I haven't looked into the exploit, but if the attack uses AMT's http(s) interface, you could also simply access the AMT port(s) from a remote machine. The service simply allows one to speak to the local ME.

xgen 9y ago

AMD have something similar to this, and there was some mentioning of this in an ama on reddit here: https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/ https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea... What are the reasons for having this, I mean good business reasons? I get that designing cpus is expensive and they reuse as much they can, and that businesses would want the benefits or remote management. However when weighed up against the damage to trust in a company is it worth it enough that they do not offer a line of chips that do not have this pseudo back door present?

wmf 9y ago
Most Intel PCs do not have AMT firmware and thus aren't affected by any AMT firmware vulnerabilities.
- xgen 9y ago
  Is management engine not on all modern intel chips, but comes disabled requiring it to be set up in the BIOS?
  - wmf 9y ago
    The ME is on all chips but the ME doesn't provide remote management. You're confusing two different things.
mdip 9y ago
> What are the reasons for having this, I mean good business reasons? So, I'll avoid writing anything about NSA collusion or related speculation and talk specifically about what you've asked -- business reasons. The main reason is that customers are already purchasing technology like this through third-party expansion cards and this kind of technology makes those (expensive) adapters less necessary for those customers if its built into the CPU. At a past company I worked at, every HP Proliant server we purchased was purchased with a PCI Express adapter that was a full computer on a card. It came with a special cable that passed the 15-pin VGA output through the card and allowed complete control of the server (and we purchased the "Lights Out" edition which included battery power so that the server could be powered on remotely). It allows one to do things you can't do through software remote management, like install the operating system, modify the BIOS settings, see POST messages at boot. It sounds like AMT offers a lot of this functionality without the need for that (I think $700) board, which would be appealing to a lot of enterprises, almost all of whom consider folks screaming about possible vulnerabilities in AMT as tin-foil-hat wearing security geeks, or have otherwise convinced themselves that "it'll never happen to me (or Intel, etc)". I, personally, tried in vein to point out the security threats that these third-party boards posed to the organization, being that the software could not be audited, was often used for years past the support date of the hardware (where security patching via firmware updates was no longer provided) and allowed complete and total access to the system in ways that even the worst OS vulnerability wouldn't (that was the point, after all), but was basically told that the benefits outweighed the risks[0]. The argument for using a management board, however, was a little easier to make than the argument for using AMT. Our security standards required that any device with a management interface be segregated to a high-security management network that, while not air-gapped, was protected via additional VPN and two-factor authentication and no access to the internet from within. It's unhelpful if the laptop of the administrator with the appropriate token is infected with something, but at least this allowed for one extra set of firewalls between those interfaces and the internet. Now...whether or not these boards were actually on said management network is anyone's guess and in the case of AMT-style software, there'd be no way to do something similar. These PCI-e boards were complete computers with their own isolated[0] network adapters. [0] I'm not positive about this one and in all likelihood a sufficiently bad vulnerability might make that separation irrelevant, but AFAIK, the network adapters on these boards were not accessible to the OS and were used by the management interface, only. If that wasn't the case, that would have made a great argument for their elimination since the management network would then be accessible via corporate (which is what the server was plugged into) without the VPN connection.

cmurf 9y ago

FTA: "the discovery of a possible zero-day in widely distributed firmware" Is this CPU firmware? Or microcode? Or is it logic board firmware (UEFI base)? And if it's CPU firmware, is that replaceable or is it permanently baked into the CPU?

orblivion 9y ago

So does this cut down the attack to people on your network? Would a simple NAT protect me here? Also it's bizarre that they're disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don't read hacker news and who aren't exactly going to update their BIOS as an everyday thing.

MichaelGG 9y ago
This feature is only active if you set it up and configure it for your company/management system. Random Lenovo customers aren't at risk. The only people at risk are companies that set AMT up, and then they should be looking for security issues with all the vendors they use.
roywiggins 9y ago
If you're not a business customer you won't have AMT provisioned, so this hack won't work remotely. Apparently a local attacker could provision AMT and then perform the attack, but that's substantially less bad.

microcolonel 9y ago

Closed source custom Java ME and ThreadX blob probably maintained by interns, running all the time with unfettered access to every resource in the system even when the machine is turned off, integrated into almost every enterprise computer network in the world. What could possibly go wrong.