TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Rediscovering the Intel AMT Vulnerability

133 点作者 xorrbit大约 8 年前

13 条评论

kbenson大约 8 年前
<i>Next, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL&#x2F;empty response hash (response=&quot;&quot; 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&#x27;s the chance something as simple as this wasn&#x27;t known by someone else? All they had to do was decide to look and they found something within minutes. It&#x27;s not like this is obscure or doesn&#x27;t get your much, it&#x27;s about as juicy as they come.
评论 #14278412 未加载
评论 #14278597 未加载
bobsam大约 8 年前
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&#x27;s the problem you should discuss, not this particular exploit.
评论 #14275931 未加载
评论 #14275339 未加载
评论 #14276173 未加载
评论 #14275332 未加载
评论 #14275881 未加载
qb45大约 8 年前
TL;DR:<p><pre><code> memcmp(received_passwd_hash, correct_passwd_hash, received_pwd_hs_len) </code></pre> Hey, at least they didn&#x27;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&#x27;s not immediately clear to me how to create equivalent bug in Java, the obvious <i>string.equals()</i> method doesn&#x27;t ignore length mismatch.<p>edit2:<p>s&#x2F;passwd&#x2F;passwd_hash to satisfy pedants below ;)
评论 #14276279 未加载
评论 #14275424 未加载
评论 #14275977 未加载
DuskStar大约 8 年前
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&#x27;t get this right, what else is wrong?
评论 #14275796 未加载
评论 #14275165 未加载
评论 #14275195 未加载
microcolonel大约 8 年前
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.
xgen大约 8 年前
AMD have something similar to this, and there was some mentioning of this in an ama on reddit here:<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Amd&#x2F;comments&#x2F;5x4hxu&#x2F;we_are_amd_creators_of_athlon_radeon_and_other&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Amd&#x2F;comments&#x2F;5x4hxu&#x2F;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?
评论 #14276222 未加载
评论 #14278469 未加载
walterbell大约 8 年前
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&#x27;t all AMT operations be performed without an OS?
评论 #14276399 未加载
MichaelGG大约 8 年前
So now that there&#x27;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&#x27;s just as bad as any bug on a remote management system? That is, the fact it&#x27;s built in to the CPU makes no difference?
评论 #14278878 未加载
评论 #14275222 未加载
orblivion大约 8 年前
So does this cut down the attack to people on your network? Would a simple NAT protect me here?<p>Also it&#x27;s bizarre that they&#x27;re disclosing this so soon, given that there are bound to be Lenovo (at least) customers who are not business customers and who don&#x27;t read hacker news and who aren&#x27;t exactly going to update their BIOS as an everyday thing.
评论 #14278265 未加载
评论 #14278274 未加载
thyrsus大约 8 年前
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 &quot;demonstrated&quot; instead of &quot;exploited&quot;, since I don&#x27;t understand the details sufficiently to rule out exploitation in the absence of LMS.
评论 #14276123 未加载
cmurf大约 8 年前
FTA: &quot;the discovery of a possible zero-day in widely distributed firmware&quot;<p>Is this CPU firmware? Or microcode? Or is it logic board firmware (UEFI base)? And if it&#x27;s CPU firmware, is that replaceable or is it permanently baked into the CPU?
RichardHeart大约 8 年前
Will blocking ports 16992 and 16993 at router block this attack (as those are the AMT ports.)?
logicallee大约 8 年前
[withdrawn]
评论 #14278131 未加载
评论 #14275752 未加载