intel cpu bug found

Anything not relating to the X-Universe games (general tech talk, other games...) belongs here. Please read the rules before posting.

Moderator: Moderators for English X Forum

apogee
Posts: 1103
Joined: Thu, 22. Jul 04, 13:35
x3tc

intel cpu bug found

Post by apogee » Thu, 4. Jan 18, 01:38


User avatar
Olterin
Posts: 603
Joined: Fri, 27. Feb 09, 21:34
xr

Post by Olterin » Thu, 4. Jan 18, 01:54

... That sounds like quite the "bug" :|

Lovely...
From Nothing, a DiD by Scion Drakhar
Tranquillity(indefinitely on hold)
"Do or do not, there is no try"
"My Other Overwhelming Mixed Assault Fleet is a Brigantine" -Seleucius, commenting on my ship naming scheme

UniTrader
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 13817
Joined: Sun, 20. Nov 05, 23:45
x4

Post by UniTrader » Thu, 4. Jan 18, 02:04

i am currently glad i have decided to use amd when i built my new rig last year...
if not stated otherwise everything i post is licensed under WTFPL

Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter ;)

I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help ;)

User avatar
ezra-r
Posts: 3087
Joined: Fri, 14. Oct 05, 21:04
x4

Post by ezra-r » Thu, 4. Jan 18, 02:24

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

User avatar
red assassin
Posts: 635
Joined: Sun, 15. Feb 04, 16:11
x3

Post by red assassin » Thu, 4. Jan 18, 02:44

ezra-r wrote: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.
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way

kohlrak
Posts: 52
Joined: Thu, 28. Dec 17, 12:47

Post by kohlrak » Thu, 4. Jan 18, 03:21

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.
Last edited by kohlrak on Thu, 4. Jan 18, 03:35, edited 1 time in total.

User avatar
red assassin
Posts: 635
Joined: Sun, 15. Feb 04, 16:11
x3

Post by red assassin » Thu, 4. Jan 18, 03:34

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.
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way

kohlrak
Posts: 52
Joined: Thu, 28. Dec 17, 12:47

Post by kohlrak » Thu, 4. Jan 18, 03:41

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.

User avatar
red assassin
Posts: 635
Joined: Sun, 15. Feb 04, 16:11
x3

Post by red assassin » Thu, 4. Jan 18, 03:52

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.
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way

burger1
Posts: 549
Joined: Fri, 21. Aug 09, 22:51
x3tc

Post by burger1 » Thu, 4. Jan 18, 04:03

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.

UniTrader wrote: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.
Last edited by burger1 on Thu, 4. Jan 18, 04:04, edited 1 time in total.

kohlrak
Posts: 52
Joined: Thu, 28. Dec 17, 12:47

Post by kohlrak » Thu, 4. Jan 18, 04:03

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.

User avatar
red assassin
Posts: 635
Joined: Sun, 15. Feb 04, 16:11
x3

Post by red assassin » Thu, 4. Jan 18, 04:18

burger1 wrote: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.

kohlrak wrote: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.
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way

kohlrak
Posts: 52
Joined: Thu, 28. Dec 17, 12:47

Post by kohlrak » Thu, 4. Jan 18, 04:31

red assassin wrote:
kohlrak wrote: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
Posts: 28395
Joined: Wed, 6. Nov 02, 21:31
x3tc

Post by pjknibbs » Thu, 4. Jan 18, 10:24

kohlrak wrote: 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.

User avatar
red assassin
Posts: 635
Joined: Sun, 15. Feb 04, 16:11
x3

Post by red assassin » Thu, 4. Jan 18, 11:47

pjknibbs wrote: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).
kohlrak wrote: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.
A still more glorious dawn awaits, not a sunrise, but a galaxy rise, a morning filled with 400 billion suns - the rising of the Milky Way

Post Reply

Return to “Off Topic English”