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.
Comments on “A Major Security Vulnerability Has Plagued 'Nearly All' Intel CPUs For Years”
I’ve been reading about the issue and maybe games won’t be as impacted as some other workloads because they don’t rely heavily on syscalls. Ars has a good article about the probable culprit.
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…
Re: Re:
I run something which uses sockets out of a VeraCrypt file on my end.
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.
Re: Re:
Also, don’t forget about Denuvo.
From the same people who brought you the Minix backdoor
Obviously, Intel was too busy installing hardware back doors to bother with protecting the poor users.
The security community has know about this since may
Bits of the minix issue have been known since May but it was mostly limited to data center users.
And I got AMD because they were cheaper for the speed.
Today I’m glad I was a cheapskate.
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.
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.
Re: 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.”
Exactly, because Nothing Said is Alarming…
Re: Re: And I got AMD because they were cheaper for the speed.
A newer article from Ars that has technical details:
https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-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.
Re: Re: And I got AMD because they were cheaper for the speed.
AMD is not vulnerable to Meltdown. Only Intel and some select ARM chips are.
Re: And I got AMD because they were cheaper for the speed.
Is this the “Intel Management Engine” issue? Where it was designed for someone on the outside to access the whole system remotely for (apparently) tech support purposes?
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.
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).
Re: Re: Re: And I got AMD because they were cheaper for the speed.
Hahahaha – remember the Pentium FDIV bug?
Re: Re: Re:2 And I got AMD because they were cheaper for the speed.
Yeah but not in detail. Are you hinting that Intel had some bogus denial? Or that they’ll need to replace CPUs now, as they did then?
Re: Re: Re:3 And I got AMD because they were cheaper for the speed.
Yeah, they said the average user would not even notice the diff … heh, it’s not the point here.
Re: Re: Re:4 And I got AMD because they were cheaper for the speed.
Well, that seems untrue, plus the papers say (at least some of) the attacks were tested and work on AMD CPUs. Good call with the FDIV comparison.
Re: Re: Re:5 And I got AMD because they were cheaper for the speed.
The papers say that “proof of concept” attacks have been constructed – which is some way short of actual practical attacks.
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.
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.
Re: Re: Re:2 And I got AMD because they were cheaper for the speed.
There is a paper on the method. Modern CPU’s can execute multiple instructions simultaneously. Speculative execution attempts to predict the future state of the CPU by assuming instructions will complete successfully. Because of this parallel nature, when a program attempts to read a value in kernel memory this triggers a whole cascade of events; Because loading data into cache is slow, this request is done first, Then a later check in the pipeline determines whether the memory read was an illegal address and rolls back the state of the CPU, but not the cache. Then the program can issue a flush-and-reload instruction to determine the state of the cache, and get the data that way. The data can be anything from passwords to usernames and account numbers.
Re: Re: Re: And I got AMD because they were cheaper for the speed.
Shite. Good to know, all the same.
Re: Re: And I got AMD because they were cheaper for the speed.
MacOS
There are indications that Apple started patching this issue in High Sierra 10.13.2.
Yet another reason...
I’ve noted for years that AMD offers motherboards with a full-speed FSB (that’s a front-side bus, not the ruski’s) while Intel continues to refuse to, and to refuse to allow their third-party board makers to either. This is a nasty trick they’ve been using since the late 90’s.
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.
Re: Yet another reason...
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.
Re: Yet another reason...
“Intel’s CPUs are almost always the best,”
Based upon what criteria?
Best at what?
Seems to be a rather broad statement.
Re: Re: Yet another reason...
They have the best fabrication technology, i.e., they’re able to make chips smaller than any other commercial-scale fab. This helps with speed and power usage, generally.
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.
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
LWN link
One of the linked articles links to a paywalled lwn.net article. Here’s a non-paywalled link.
definition please.
What exactly does an embargo on the security flaw mean? That they won’t share with anyone besides the effected party?
Re: definition please.
I know the definition of embargo itself but how is it applied in this context? Also who orders the embargo when potentially multiple countries are involved?
Re: Re: definition please.
“Embargo” means the people involved have agreed not to release details right now… presumably until a certain date, or until a patch is available. Obviously, the people writing these patches must have more information than the rest of us.
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.)
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.
dont worry about the slow down after any update patch has been applied, Intel will soon sell you a nice, new, faster chip at 3x the cost of the ‘faulty’ one!
Re: Re:
Sounds like Apple’s business strategy.
Re: Re:
Anything still under warranty should be repaired or replaced. But outside the warranty is no different than anything else you might buy.
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.
Re: Re: Re:
But one would have discovered rather soon that their Mazda could not reach highway speeds and take it back to the dealer immediately.
Oh yeah – car analogies are bad, all of them – this is no different.
Re: Re: Re: car analogies?
Actually, there is one very obvious motorcar analogy.
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.
Re: Re: Re:
Or your 2018 Mazda. Totes no difference.
Gosh, I wonder if Intel’s CEO flushed a whole bunch of stock options recently…
Re: Re:
Um, actually, he DID.
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
And again. Backdoors make it into the wild every time. Everybody wave their hands in the air in pretend panic as the backdoor is closed, and a new backdoor is tunneled in to replace it.
Re: Re:
Uh, this wasn’t a backdoor. It’s just an undiscovered (until now) bug.
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.
Re: 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.
Re: Re: Re: Re:
“if an agency wanted to defend their country”
They would look for these things in order to eradicate, not use.
Re: Re: Re:2 Re:
Yes, of course! They have the expertise to find this, and they’d screw themselves by hoarding it; other agencies are depending on CPUs to be secure. Though really, CPU manufacturers should be releasing enough information so we don’t have to rely on powerful agencies.
Re: Re: Re: Re:
Read my post a little more thoroughly please.
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.
Re: Re: Re:2 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.
Re: 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.
Re: Re: Re:
Let’s see now. At the very least, being able to just detect where some critical kernel pages are located neutralizes Kernel Address Space Layout Randomization, aka last ditch effort to keep buffer overflow attacks from working. Then, you have the row hammer exploit to elevate permissions. And guess what? In order for row hammer to work, you need to know where the addresses of critical kernel structures are. And the above 2 attacks don’t even require you to actually know what is in those locations, merely need to know that it’s in that location. And if the exploit actually allows you the ability to read kernel memory? At that point, you might as well give your computer to your enemy.
Re: 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.
Re: Re: Re:
This exploit allows reading of protected memory and could for instance be combined with a rowhammer attack to effect privilege escalation.
Re: Re: Re: Re:
Yep, it could be used in combination with another attack to get privilege escalation but as I stated in my original comment, by itself this only gives you info, not any kind of meaningful control or access.
Re: 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.
Remember that time,
when Intel DIDN’T have a maths co-processor problem on their 585.999938 CPU?
Update
Seems there are two different flaws, one of which affects a range of non-Intel CPUs.
(h/t Michael Cree)
No wonder the tekkies are all leaving NSA...
Most of their favorite exploits have been found, so it’s no longer any fun…
If it’s patched in the Linux kernel, then the bug is basically in the open already. People will reverse engineer the fix to find out what the cause is. They’ve done the same for security updates from vendors for years. So why still embargo it? Reveal the details of what’s affected and the patches available, even if you don’t release POC code. Hackers are going to work out an exploit anyway.
Normal laptop and desktop users will notice little delta
This is an optimization (cough,cough) that allowed a system to run faster. The fix is relatively simple; Separate kernel address from user address. That comes at a cost, but many user space applications will notice little to nothing at all.
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.
And the white papers are out
full details on the vulnerability are now out.
https://meltdownattack.com
Meltdown mitigated in Linux Kernel 4.14.11
Which just has been released. Some distros did patch older kernels themselves.
Actually, 4.14.12 is out as well, https://www.kernel.org/
i5-7200U CPU @ 2.50GHz - Do i have to worry ..?
My laptop has the following processor
“model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz”
do i have to worry about the above mentioned vulnerability issue ..?