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:

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.

Filed Under: , ,
Companies: intel

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “A Major Security Vulnerability Has Plagued 'Nearly All' Intel CPUs For Years”

Subscribe: RSS Leave a comment
63 Comments
Ninja (profile) says:

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…

Anonymous Coward says:

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.

Anonymous Coward says:

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.

Anonymous Coward says:

Re: Re: And I got AMD because they were cheaper for the speed.

Is this the "Intel Management Engine" issue?

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).

Richard (profile) says:

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.

Anonymous Coward says:

Re: Re: Re: And I got AMD because they were cheaper for the speed.

it may be an infoleak related to speculative execution

…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.

Mikael says:

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.

Anonymous Coward says:

Re: 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?

No. Also, the word you’re looking for is “ostensibly” rather than “apparently.”

Chuck says:

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.

An Onymous Coward (profile) says:

Re: 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.

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.

Anonymous Coward says:

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.

Anonymous Coward says:

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.

Anonymous Coward says:

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.)

An Onymous Coward (profile) says:

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.

carlb (profile) says:

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.

Anonymous Coward says:

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.

Anonymous Coward says:

Re: Re: Re:

Uh, this wasn’t a backdoor. It’s just an undiscovered (until now) bug.

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.)

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.

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.

Anonymous Coward says:

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.

Anonymous Coward says:

Re: Re: Re:2 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.

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.

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.

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.

Richard (profile) says:

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.

Anonymous Coward says:

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.

Anonymous Coward says:

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.

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.

Anonymous Coward says:

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.

David (profile) says:

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.

Leave a Reply to Mikael Cancel reply

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Ctrl-Alt-Speech

A weekly news podcast from
Mike Masnick & Ben Whitelaw

Subscribe now to Ctrl-Alt-Speech »
Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...