intel cpu bug found

[apogee]

going to mean reduced performance

lovely....

[Olterin]

... That sounds like quite the "bug"

Lovely...

[UniTrader]

i am currently glad i have decided to use amd when i built my new rig last year...

[ezra-r]

it would be nice to know which exact models are affected.

[red assassin]

it would be nice to know which exact models are affected.

The short version is "yes".

The longer version is - any processor with any form of speculative execution is potentially vulnerable to some forms of the attack. This is pretty much every modern non-embedded CPU at least, and potentially includes a lot of embedded chips as well. From what's been released so far I would say that it looks highly likely that any Intel processor is vulnerable to the simpler/more obvious forms of the attack.

Project Zero have been able to demonstrate the attack on an AMD processor as well, despite AMD's claims not to be vulnerable, in the very specific circumstances that user-controlled code can be inserted into the kernel (in this case, via the eBPF JIT kernel module). There are likely to be other variants of these circumstances discovered. This is why I say I suspect nearly every processor is going to be vulnerable to some forms of the attack, just not the easy version that applies to Intel.

Ultimately this comes down to the fact that making your CPU faster in some, but not quite all, circumstances necessarily leaks information about what those circumstances are - this is the cost of caching. I imagine variants of this attack will continue to pop up for years, despite the performance-costly mitigations installed in the latest versions of the Linux and NT kernels.

[kohlrak]

I'm a bit more curious about what they plan on doing. First off, how is the memory vulnerable? Is it writable or just readable? How do they plan on hiding the kernel from the user? Better question yet, how did this get by for so long without anyone noticing? I thought PMODE was effectively established long ago and that you can't read ring 0 from a lower ring.

EDIT: Apparently intel's admitting the readable bit, but then i'm guessing this has more to do with PAE mode than anything. I never used it, tbh, so I don't know how it works. In theory, everyone who designs kernels should've known about this. Intel even says that it's documented. And they're right that this affects almost all, if not all, processors out there. I'm not sure if it affects ARMs (androids and iPhones use this) or not. I remember thumb mode ARM have separate code and data RAMs (thus the code is only readable by privileged instructions to begin with), but i'm not sure if that's true with the mainline ARMs.

[red assassin]

There's really two separate issues here. See https://meltdownattack.com/ for more. Both of them are read issues only, there's no indication that any of this can be used to write.

"Meltdown" (sigh, everything needs a cool name now) is a flaw in Intel's microarchitecture which allows data from ring 0 to leak into the processor cache (from which it can be extracted via timing attacks) via careful manipulation of speculative execution. The privileged data is never explicitly accessible to the unprivileged process, but it alters the processor state in detectable ways. This is fixed in current development versions of the Linux and NT kernels by a method referred to as "KAISER", which scrubs a lot of processor state when transitioning from kernel to user mode, at the cost of performance (because that cached data is cached for a reason!).

"Spectre" is a more general expression of the fact that modern CPUs do speculative execution, and in some cases you can exploit that to leak data you shouldn't be able to via timing attacks. This doesn't allow crossing privileges directly, but in some cases you can do stuff like ask the kernel to do something vulnerable and time the result. There is no easy, single mitigation for this issue - it's a function of how CPUs work, and the only real approach is to try and scrub vulnerable code patterns from applications. This is going to be with us for a long time and there will be new and exciting variants of it appearing, I'm sure.

[kohlrak]

Firstly, Linux is open source, so I don't see why that's an issue for Linux. Secondly, the kernels are usually available in their non-running form to any process, anyway. You should build your kernel with the assumption that the attacker has access to it. Properly gate your kernel calls with syscalls and mind your own callstack usage and they shouldn't get in.

[red assassin]

This isn't necessarily about being able to read the kernel's code (although that can be useful too in case of ASLR and other similar mitigations) - it allows you to read *any* privileged memory. That's incredibly powerful in enabling exploitation of other kernel bugs, but it also allows you to read sensitive data directly. Linux, for example, maps the entire physical memory into the kernel's virtual address space, meaning you can read memory from any process on the system as well as the kernel using this attack.
edit: I'll be quite surprised if somebody doesn't get Meltdown working from JavaScript in some form, and the idea of random JavaScript being able to read any memory on your system should be properly scary.

[burger1]

AMD is getting "fixed" also. Maybe it's their way of getting people to buy new cpus since there really hasn't been much change in terms of speed for years.

i am currently glad i have decided to use amd when i built my new rig last year...

https://www.forbes.com/sites/davealtavi ... e639a8570a

To be clear, these software patches are being released and will apply this fix for all processors, regardless of processor type in the targeted system. In other words, though AMD processors are not effected and are not subject to this vulnerability, applying the patch would regardless also result in possible performance degradation. Thomas Lendacky, a member of the Linux OS group at AMD reports “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.” As such, AMD is currently not recommending patching systems for this Intel bug, though again, it will likely be pushed from OS vendors, regardless.

[kohlrak]

Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

edit: I'll be quite surprised if somebody doesn't get Meltdown working from JavaScript in some form, and the idea of random JavaScript being able to read any memory on your system should be properly scary.

The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

EDIT2: I'm not finding any way for javascript code to do that, actually, though a bad browser could have a bug or "feature" that would allow it. Javascript doesn't allow pointer manipulation.

[red assassin]

AMD is getting "fixed" also. Maybe it's their way of getting people to buy new cpus since there really hasn't been much change in terms of speed for years.


https://www.forbes.com/sites/davealtavi ... e639a8570a

To be clear, these software patches are being released and will apply this fix for all processors, regardless of processor type in the targeted system. In other words, though AMD processors are not effected and are not subject to this vulnerability, applying the patch would regardless also result in possible performance degradation. Thomas Lendacky, a member of the Linux OS group at AMD reports “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.” As such, AMD is currently not recommending patching systems for this Intel bug, though again, it will likely be pushed from OS vendors, regardless.

The Meltdown mitigation is not applied to AMD processors on Linux - that quote from Lendacky is attached to a patch which makes exactly that change. I imagine NT will do the same.

There is no central mitigation for Spectre, which does affect AMD processors as well.

Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

The gist I'm getting here is "other security flaws exist so we shouldn't patch security flaws". This seems like a flawed argument to me. Sure, there'll be other bugs, and we should fix those too. But granting the ability to any executing code to read any memory on the system, which appears to be the effect of Meltdown, undoes pretty much the entire separation of privileges security model. All of the work done by sandboxing, user accounts, elevation levels, the kernel, etc etc in isolating sensitive bits of the system from other parts - user credentials, crypt keys, the user's actual data, etc etc - goes out of the window in one fell swoop. If you work hard enough you can get past any of those methods of isolation, but it's hard - Meltdown makes all of it easy in one handy attack.

JavaScript can't read browser memory without some form of exploit.

[kohlrak]

Most people, out of laziness (or maybe due to compiled code restrictions regarding the segment registers), do map the entire memory to kernel address space. They shouldln't, though. Ring 0 can use a lower ring's segment, IIRC.

Moreover, these OSes typically have something similar to the HOOKS API, which essentially allows any program to access any other program's RAM, regardless (which is why so many games are trying to implement cheat protection). Realistically, this isn't offering us anything new aside from the realization that people have been doing things wrong for a very long time. By the looks of things, what they're planning to do to solve it not only won't solve it, but doesn't even attempt to address the problem.

In other words, we have new exploits that help people do the things that they could already do, anyway. Anyone who's shocked by this was living under a rock. Even Intel seems to be approaching it this way.

EDIT:

The idea of javascript even reading the browser's memory is scary enough to me. We've been overly kind with what these scripts are able to do. The irony is that alot of these things had security in mind originally, but fell apart later, because I guess that's intel's job?

The gist I'm getting here is "other security flaws exist so we shouldn't patch security flaws". This seems like a flawed argument to me. Sure, there'll be other bugs, and we should fix those too. But granting the ability to any executing code to read any memory on the system, which appears to be the effect of Meltdown, undoes pretty much the entire separation of privileges security model. All of the work done by sandboxing, user accounts, elevation levels, the kernel, etc etc in isolating sensitive bits of the system from other parts - user credentials, crypt keys, the user's actual data, etc etc - goes out of the window in one fell swoop. If you work hard enough you can get past any of those methods of isolation, but it's hard - Meltdown makes all of it easy in one handy attack.

JavaScript can't read browser memory without some form of exploit.

Let me tell you what you should read from it: there's a proper layer for security, and what we're talking about isn't it.

When OSes, in practice, are providing their own methods of thwarting the protection, why is the cache thing even an issue? The consistent statement of the OSDEVs is that reading the kernel's memory, as well as 2 ring 3 programs reading each other's memories, is not a problem. Only now has the message changed, and it sounds more like a response to fear of the media more than actual concern. Intel put the cache control instructions in the processor for a reason. If you're not OK with something being cached, you shouldn't allow it to be cached. It's up to the kernel devs to make this happen, not intel.

The OSes we use are inherently insecure. Proper gating techniques work for code execution. As for read level, even before caching it was insecure. It's the OS devs that made it insecure, not intel. The instructions there to prevent these issue always existed, except no one bothered to implement them, even to the degree that the same OS Devs made it so you can thwart the read protection without the cache issues, and this was intentional.

There never was a bug: people just made incorrect assumptions: the OS devs for assuming they didn't need to use the cache management instructions, and everyone else for assuming that it wasn't an OS design flaw.

[pjknibbs]

When OSes, in practice, are providing their own methods of thwarting the protection, why is the cache thing even an issue? The consistent statement of the OSDEVs is that reading the kernel's memory, as well as 2 ring 3 programs reading each other's memories, is not a problem.

Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

[red assassin]

Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

There are APIs like the helpfully named ReadProcessMemory in Win32, but that requires specific privileges and doesn't just allow you to crash around reading anything's memory. kohlrak seems to be unaware of the last decade of work on the separation of privileges in Windows - this would have been a fairly fair characterisation in the XP days when basically everything was administrator and you could load unsigned drivers, but we're a long way from that now. As far as I know Linux has never been as bad as claimed (though they've certainly tightened up kernel isolation too).

There never was a bug: people just made incorrect assumptions: the OS devs for assuming they didn't need to use the cache management instructions, and everyone else for assuming that it wasn't an OS design flaw.

Isn't "people just made incorrect assumptions" exactly what a bug is? Just because you think this is obvious in hindsight doesn't mean it was - there's a giant gulf between "this is documented behaviour" and "this documented behaviour allows the following security breaches", and the fact that it's been two decades since Intel introduced speculative execution in the Pentium Pro before anybody figured this out should demonstrate that. I think this particular behaviour ("Meltdown") is surprising, and not an obvious consequence of the way processors work, especially given AMD isn't vulnerable. (The fact that Spectre like attacks are possible is less surprising, and they're also a lot fiddlier to pull off.) I also don't think you can pin all the blame on OS developers, given x86 provides instructions (SYSENTER family) specifically to allow getting to ring 0 without expensive operations like interrupts and cache flushes - this is clearly the way it's meant to be used, or SYSENTER etc would just flush caches.

[Bishop149]

Ok, reading this has enlightened me slightly but its pretty clear my knowledge of a computers architecture is no where near sufficient for me to fully grasp the problem. So in my mostly laymans terms: Does a regular PC owner actually have to worry about this? Or is it mostly gonna be a problem for business concerns who may actually have data worth stealing?

I'd imagine that should I want to fix this it would be an absolute arse, updating the firmware on a chip or something. Something I could probably manage (but wouldn't enjoy) but that I bet 95% of PC owners couldn't.

[pjknibbs]

You may not think you have data worth stealing on your machine, but what about the passwords for your online banking? Stuff like your mother's maiden name that could be used for identity theft? If it's sufficiently easy to steal stuff like that then it becomes worth doing, and this flaw makes it a *lot* easier to steal that stuff.

Is it likely you'll be specifically targeted? Of course not, but a malicious program dropped into a website doesn't care who's browsing the site, it'll just take the stuff and its controllers will figure out later what they can do with it.

[Bishop149]

Ok, I'm convinced.

So it then becomes about implementing a fix. Any idea what form it might take? Nice easy automatic update or pain in the ass flashing a chip.
Also I'm interesting by the commercial implications of a manufacturer having to make their products substantially less effective in order to make them safer due to a screw up they made. Many might feel they are owed a refund of some kind.

Edit: Oh ok, pretty easy. At least for the Meltdown one: https://support.microsoft.com/en-us/hel ... -kb4056892

[Antilogic]

https://meltdownattack.com/

Please be aware this is not an Intel only issue. Please consider this to affect all your devices and (as you should ALWAYS do) update and patch as soon as possible.

Patches are available for Security Supported Microsoft, Apple, Google and most other major devices.

[Bishop149]

I just ran a check for Windows updates on my work machine. . . . . apparently there aren't any. Checked the OS version and yep its the applicable one.
This below certainly implies the fix is officially rolled out and not a work in progress to be applied manually.

"This update will be downloaded and installed automatically from Windows Update."