A Major Security Vulnerability Has Plagued 'Nearly All' Intel CPUs For Years
from the whoops-a-daisy dept
Intel is in for a very challenging few weeks. Reports began to bubble forth this week suggesting that "nearly all" intel chipsets (and some chipsets from other vendors) have been plagued by a security vulnerability over the last decade that could impact millions upon millions of users. While the full details of the vulnerability have been largely been kept under secret embargo by the security community, the scale of the flaw appears to be monumental. From what's currently known, the vulnerability currently allows programs to gain access to the layout or contents of what previously was believed to be protected kernel memory.
You know, the area where everything from passwords, login keys, and files cached from disk are presumably stored away from prying eyes. The problem appears to be unprecedented, and the entire security community is rushing to quickly push out updates for the problem:
"There is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.
So for one, this appears to have been in the wild for years, raising questions as to whether this has already been exploited by the intelligence community and others. And while the nature of the vulnerability isn't being fully disclosed, AMD hinted at the structure of a problem in an e-mail over the holiday to the Linux kernel mailing list stating that AMD products aren't affected:
"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
At least one computer science PHD candidate at Vrije Universiteit Amsterdam claims to have already developed a proof of concept capable of exploiting the flaw to read kernel memory from user mode:
Bingo! #kpti #intelbug pic.twitter.com/Dml9g8oywk
— brainsmoke (@brainsmoke) January 3, 2018
And while the vulnerability can be patched on the OS level (patches for the Linux kernel are already available even though the notes try to tap dance around the true nature of the issue), early reports indicate these updates could come with a much as a 30% performance penalty, something that will make gamers and other enthusiasts likely weep:
"Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary."
In other words, Intel's not only about to take a severe beating for a massive security vulnerability, but the performance of much of its product lineup is about to be dramatically impacted by the fix, which could flood the market with people looking for new, unimpacted CPUs. That's likely great news for AMD sales, but notably less so for Intel PR reps coming off of their holiday break, who'll be tasked with softening the perceived impact of the flaw ahead of more details in a week or two.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
As CPUs get more and more complex we are introducing more attack surface like that case where Intel stuff was running an entire OS with full access to the system core functions. I expected unintended consequences like this to be a lot more common in the future. I'd love to say criminals around the world are thrilled but I don't think they are as thrilled as our authoritarian govts...
[ link to this | view in chronology ]
Re:
So I either have to patch which makes this situation completely unworkable because of the sheer amount of I/O system calls...
...or remain vulnerable.
So fair, vulnerability is winning.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
From the same people who brought you the Minix backdoor
[ link to this | view in chronology ]
The security community has know about this since may
[ link to this | view in chronology ]
And I got AMD because they were cheaper for the speed.
Today I'm glad I was a cheapskate.
[ link to this | view in chronology ]
Re: And I got AMD because they were cheaper for the speed.
It's not clear yet whether AMD processors have the same flaw. It may even exist on ARM chips.
As Ninja noted, Ars has a good rundown of what we know so far.
[ link to this | view in chronology ]
Re: Re: And I got AMD because they were cheaper for the speed.
That's true until we know the details, but they denied this class of bugs with some specificity. Compare that with Intel's non-statement.
[ link to this | view in chronology ]
Re: Re: Re: And I got AMD because they were cheaper for the speed.
Exactly, because Nothing Said is Alarming...
[ link to this | view in chronology ]
Re: Re: And I got AMD because they were cheaper for the speed.
https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfi xable-security-flaws/
Doesn't really list what's affected though... seems like the answer to that is 'everything' - Intel, AMD and ARM.
Ars reports the patches for some usage scenarios may result in a 40-60% slowdown. That's an incredibly high penalty. But I suppose the vendors will refine patches later and push down the penalty to a lower figure.
[ link to this | view in chronology ]
Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: And I got AMD because they were cheaper for the speed.
I've heard that AMD CPUs also have a similar function, so don't think that switching to them will save you. Even if their implementation claims to be completely different, it just means that it hasn't been broken to our knowledge, yet.
[ link to this | view in chronology ]
Re: Re: And I got AMD because they were cheaper for the speed.
The information we've seen suggests it isn't, and that it may be an infoleak related to speculative execution. See AMD's statement, and note that some sources are saying CPUs since the Pentium Pro are affected (they seriously predate the IME).
[ link to this | view in chronology ]
Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
I also remember the 8087 evaluation stack cock-up - which persisted for many years. In fact it is still technically present in the instruction set to this day.
[ link to this | view in chronology ]
Re: Re: Re: And I got AMD because they were cheaper for the speed.
...and to speculate wildly myself, the CPU must be somehow speculating on secret data. Maybe the result then feeds into the cache or the branch predictor in some user-observable way. Here's a similar thing from last year, involving TSX.
I might start by writing some code that jumps to a kernel address. Run it and handle the fault, or just make the CPU predict the jump will be taken. Then probe the cache or predictor state to get some data. Maybe using the address of a register-dependent jump instruction will make the CPU prefetch based on the (userspace-controlled) register value.
[ link to this | view in chronology ]
Re: Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: Re: And I got AMD because they were cheaper for the speed.
[ link to this | view in chronology ]
Re: Re: And I got AMD because they were cheaper for the speed.
No. Also, the word you're looking for is "ostensibly" rather than "apparently."
[ link to this | view in chronology ]
MacOS
[ link to this | view in chronology ]
Yet another reason...
In short, they make a new CPU that actually is marginally faster than the last one AMD released. Then, they do a limited run of boards with full-speed FSBs and put them in the review units they send to various hardware reviewers. Then the rest of us, even the people who pay upwards of $600 for a motherboard, are stuck with lower-speed FSBs.
The end result is that, even though Intel's CPUs are almost always the best, their actual systems are not overall faster than AMD's. They appear to be in most testing, but in practice they aren't.
Then when enthusiasts who actually care about that last 5% of performance actually benchmark their systems, they're slower than they expected. So the cycle begins anew. The whole thing is a marketing gimmick that isn't even actually illegal because the speed of the FSBs is disclosed to the reviewers. It isn't pointed out that ONLY reviewers will EVER see this FSB speed, but then the law doesn't require that.
Just yet another reason I prefer AMD systems. Their CPUs may be SLIGHTLY slower, but overall their systems are faster, because they're more interested in selling you a decent computer than in shoveling you into the most vicious upgrade cycle they can think of.
[ link to this | view in chronology ]
Re: Yet another reason...
If there weren't end-user-driven stats sites out there to get the real performance data (ignore all those reviews sites) this might be a real concern. However, Intel is still the better buy, as long as you go with coffee lake. For now.
Sooner or later I expect AMD will take the lead again but it has been a really long time since the last inversion.
[ link to this | view in chronology ]
Re: Yet another reason...
Intel also disable ECC memory on most non-Xeon CPUs. (Some non-Xeons are rumoured to support it, but it's hard to find official details.) ECC may help prevent certain memory-corruption attacks like Rowhammer, which may or may not be related to this flaw.
AMD's Ryzen processors all have ECC capability—though, sadly, details on mainboard/firmware support are hard to find.
[ link to this | view in chronology ]
Re: Yet another reason...
Based upon what criteria?
Best at what?
Seems to be a rather broad statement.
[ link to this | view in chronology ]
Re: Re: Yet another reason...
Until AMD released Ryzen, Intel got higher scores on most CPU performance benchmarks (but cost more, so "better" is subjective). It's been like that through most of their history, except in the Pentium 4 days when AMD got higher scores. And now with Ryzen, which is competitive too.
[ link to this | view in chronology ]
Re: Re: Re: Yet another reason...
They have the best fabrication technology,
But they are crap at designing processors and have a long litany of historical design cock-ups to show for it.
In an ideal world AMD or ARM would design the chips nad Intel would make them
[ link to this | view in chronology ]
LWN link
One of the linked articles links to a paywalled lwn.net article. Here's a non-paywalled link.
[ link to this | view in chronology ]
definition please.
[ link to this | view in chronology ]
Re: definition please.
[ link to this | view in chronology ]
Re: Re: definition please.
This would have been negotiated between the researchers and the affected companies/groups. In general nothing stops researches from publishing immediately. It seems they, Intel, AMD, Microsoft, and some Linux developers have the details, at least, and have agreed not to share them.
("Embargo" in this context is similar to the journalistic concept of an "embargoed" story.)
[ link to this | view in chronology ]
Re: Re: Re: definition please.
Intel's bug bounty program offers $30000 for a critical hardware bug, but participants "Must follow coordinated disclosure" to get paid.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
If the engine in your 2012 Mazda dies you might be upset at Mazda for poor quality or upset at the universe for your bad luck but you have no recourse. Your options now are to buy another Mazda or some other brand. Or, I suppose, stop driving. This is no different.
[ link to this | view in chronology ]
Re: Re:
Oh yeah - car analogies are bad, all of them - this is no different.
[ link to this | view in chronology ]
car analogies?
Buy a VW Diesel on the presumption that it is efficient, powerful and clean... then get told later to "choose any two" after the vehicle fails a third-party emission road test and the proposed fixes cost efficiency, power or both.
The product is still running; that doesn't mean something doesn't stink here.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
It isn't even a write attack, it's read only. Meaning someone exploiting this could only get information from the PC, not make it do anything. Though one could make the argument that what is revealed in this exploit could be used to chain an additional attack that would lead to privilege escalation and an eventual write attack but this by itself, doesn't do that.
[ link to this | view in chronology ]
Re: Re:
What were you expecting, MSR_NSAKEY? If one wanted to design a backdoor, this would be pretty much perfect. (Or if an agency wanted to defend their country, it's exactly what they should be looking for: areas where a designer might fuck up. CPU design—including caching, speculative execution, and protection, and the interactions between them—is hard.)
You may not have thought this through. If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed. This is why Heartbleed was considered so critical.
[ link to this | view in chronology ]
Re: Re: Re:
They would look for these things in order to eradicate, not use.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
I acknowledged that this could be used in combo with another attack to actually take control of or modify the computer in some way, but BY ITSELF can't do any of that.
My point was more to address the OP's seeming assumption that this was a deliberate backdooring of hardware and that even if it is fixed, they will deliberately insert a new one. This is not that, it's a flaw, plain and simple.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Once you dump the password or key from memory, using it isn't much of an "attack". If attackers can't run code on the system, dumping kernel/hypervisor memory does require some preceding attack; but lots of systems do let people run code, and this is a serious vulnerability. Chaining isn't generally that hard anyway, and this can break a lot of attack mitigations.
To say this is only an information leak is true but makes it sound much less serious than it is.
Unless you were on the Intel engineering team that screwed up, you can't know that for sure. I suspect you're right, but (in hindsight) this would be an ideal backdoor because it can be written off as a complexity-induced bug. It sat around for decades before being noticed. And Intel's next CPU will be even more complex, meaning the next bug/backdoor can hide the same way.
Any "sufficiently advanced bug", like this or the SetAbortProc WMF bug, is indistinguishable from a backdoor.
[ link to this | view in chronology ]
Re: Re: Re:
. If one can get information like passwords or encryption keys, one can use them to "do things" that shouldn't be allowed.
It doesn't seem that that kind of information would be accessible to these exploits without some other route in. It is only possible to determine the layout of the data in the kernel memory - not its contents.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
Yeah, I acknowledged it could be used IN COMBINATION with another attack to actually create a backdoor into the system, but BY ITSELF this is not that.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
This exploit allows reading of protected memory
No it doesn't - it allows the determination of which parts of protected memory are in use.
[ link to this | view in chronology ]
Remember that time,
[ link to this | view in chronology ]
Update
Seems there are two different flaws, one of which affects a range of non-Intel CPUs.
(h/t Michael Cree)
[ link to this | view in chronology ]
No wonder the tekkies are all leaving NSA...
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Normal laptop and desktop users will notice little delta
I shared the description with another software retiree and he laughed. Yes, this is something that any security person would jump on. Of course, software issues much less opinions of software or security people are commonly ignored.
Because chip designers are godlike. Just ask them.
[ link to this | view in chronology ]
And the white papers are out
https://meltdownattack.com
[ link to this | view in chronology ]
Meltdown mitigated in Linux Kernel 4.14.11
Actually, 4.14.12 is out as well, https://www.kernel.org/
[ link to this | view in chronology ]
i5-7200U CPU @ 2.50GHz - Do i have to worry ..?
“model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz”
do i have to worry about the above mentioned vulnerability issue ..?
[ link to this | view in chronology ]