<i>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).<p>Authentication still worked. We had discovered a complete bypass of the authentication scheme.</i><p>What. the. fuck.<p>This is not the kind of bug you should ship in <i>anything</i> 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?).<p>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.
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.<p>That's the problem you should discuss, not this particular exploit.
TL;DR:<p><pre><code> memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len)
</code></pre>
Hey, at least they didn't read past the submitted buffer.<p>edit:<p>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 <i>string.equals()</i> method doesn't ignore length mismatch.<p>edit2:<p>s/passwd/passwd_hash to satisfy pedants below ;)
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?
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.<p>What could possibly go wrong.
AMD have something similar to this, and there was some mentioning of this in an ama on reddit here:<p><a href="https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/" rel="nofollow">https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...</a><p>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?
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?<p>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?
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?<p>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?
So does this cut down the attack to people on your network? Would a simple NAT protect me here?<p>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.
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?<p>[0] I say "demonstrated" instead of "exploited", since I don't understand the details sufficiently to rule out exploitation in the absence of LMS.
FTA: "the discovery of a possible zero-day in widely distributed firmware"<p>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?