flat assembler
Message board for the users of flat assembler.

flat assembler > Main > [Not only Intel] CPUs vulnerability

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
https://www.theregister.co.uk/AMP/2018/01/02/intel_cpu_design_flaw/
John Leyden and Chris Williams wrote:
In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

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.

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to obey, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.

That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.

The specifics of the vulnerability have yet to be confirmed, and this discussion of its severity is – aptly enough – speculation, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it's more serious than a KASLR bypass.
Post 03 Jan 2018, 13:04
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
Damn I just posted about the same thing but in the Heap, I should've looked first. Razz
Post 03 Jan 2018, 18:11
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
The papers have been released: https://meltdownattack.com/

Apparently the same design flaw is present in AMD and even ARM processors. It is in fact a deep-rooted problem of how the modern CPUs are designed in general. All the mechanisms needed for these exploits should already be well known to any experienced assembly programmer visiting this board, they just had to be put together in the right way.
Post 04 Jan 2018, 00:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
Post 04 Jan 2018, 09:22
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
Yet another reason to disable JS. One never knows what sensitive information some random website has discovered by exploiting the flaw.
Post 04 Jan 2018, 12:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
It should be interesting to read more about the mitigations that are going to be implemented in hardware and software. I recall how ingenious the workarounds for F00F bug were, but this time we have a set of much more complex problems. Any true solution (I mean one directed at the real source of these problems, not just one making it harder to exploit specific variants) would need to be ingenious, too.

The simplest thing that comes to my mind would be to have any updates of cache made by speculatively pre-executed instructions be conditional (suspended?) just like the actual updates of memory are. But that would require some serious work in the hardware and might harm the performance nonetheless. Could something like that be practical? Well, I don't know, I'm an assembly programmer, not a CPU designer. Wink
Post 04 Jan 2018, 13:07
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
Meltdown only affects Intel though.

Spectre doesn't even have patches for it. RIP.
Post 04 Jan 2018, 13:24
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
Furs wrote:
Meltdown only affects Intel though.
The specific variants may work or not on a given CPU, depending on various architectural details. But I see these exploits as a different faces of the same deeply rooted design problem. For an assembly programmer it is not hard to imagine that there may still be many other variants possible.

Furs wrote:
Spectre doesn't even have patches for it. RIP.
The Get-SpeculationControlSettings script (described in the link I provided above) has a line that looks like this:
Code:
Hardware support for branch target injection mitigation is present: True/False    
So apparently there already exists some solution on the hardware level. I would love to know more about it.
Post 04 Jan 2018, 13:30
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
And their "proof of concept" targeted Intel Haswell Xeon CPU (exactly what I have), just fantastic, is this some sort of sign that God exists and wants to fuck with me?

Kind of pissed right now. It's not like it's a common CPU, on the contrary.
Post 04 Jan 2018, 13:40
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
Of course in an ideal world Intel shouldn't care less if some ring-3 code can in fact read (or even write) ring-0 data. It's only the likes of Micro$oft who really care...

_________________
FAMOS - the first memory operating system
Post 05 Jan 2018, 07:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6968
Location: Kraków, Poland
A whitepaper from ARM: https://developer.arm.com/support/security-update/download-the-whitepaper

Quote:
This side-channel can be used to determine the values held in system registers that should not be accessible. While it
is undesirable for lower exception levels to be able to access these data values, for the majority of system registers,
the leakage of this information is not material.
Now this way of stating it is a bit unsettling. What if one day contents of some such registers turn out to be "material" after all? It is perhaps too late to do anything about it in the current generation of processors, but future designs should not dismiss this problem.
Post 05 Jan 2018, 10:11
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 529
Now this is creepy.

Sources from the deep saying that thousands of hackers and evil coders are now crafting their pieces to re-produce Spectre as we speak. Expect chaos for the upcoming months. Intel CEO sold his shares already. LOL.

In the mean time, I suggest you peeps avoid making progs with branches. If necessary, make your branches and Jcc as stupid as possible. At least it will slow the hackers down. Kidding ;D
Post 05 Jan 2018, 20:31
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
fasmnewbie wrote:
Sources from the deep saying that thousands of hackers and evil coders are now crafting their pieces to re-produce Spectre as we speak. Expect chaos for the upcoming months. Intel CEO sold his shares already. LOL.
At least he's a smart investor Wink Whether this is FUD or not, it's expected that the stock will go down, people work like that.
Post 06 Jan 2018, 15:26
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3475
Location: Bulgaria
Well, for me, the worse problem is the Meltdown bug. How good my AMD A4-1200 netbook is safe. As well, as my daughter Ryzen desktop. Razz

Spectre, looks more like theoretical attack vector and exploiting it seems to be very questionable. At least that is my impression reading several articles across Internet.
Post 06 Jan 2018, 18:08
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 286
Location: Australia
Spectre is definitely not theoretical, their release included PoC code in both C and Javascript. IMO this is realistically only a real threat for the NodeJS/Javascript/Browser-JS/etc communities where running third-party/untrusted code is a regular practice (think of the npm ecosystem, haha, scary stuff). Spectre gives me access to _my own process' memory_, so if you can imagine being able to arbitrarily dump your own memory, well there you have it. In most cases, including all of my own, I already have access to my own memory in my running processes, which is why this isn't a concern. In the Javascript/NPM (and several others of course), where running other people's code in your process space (or in their PoC case, a browser running JS) you can see that being able to access the parent process memory could be a bad thing security-wise.

Meltdown however is an entirely more scarier thing IMO. I spent yesterday doing a preliminary once-over (since they haven't yet released PoC code for it). I'll summarise by saying: Meltdown gives an unprivileged user the ability to dump the entirety of physical RAM in a machine, bypassing ring0/ring3 protections.

In saying that, I wrote a test case for it and was unable to reproduce it thanks to my missing what they call a "precondition" that is required, which they suggest in a roundabout-way is that the kernel/target memory must reside in the L1 cache in order to circumvent the "race condition" between speculative execution and the privilege check and subsequent interrupt/error/fault. I am still working on it Smile

In summary, Meltdown is way way worse but I have yet to reproduce it...
Post 06 Jan 2018, 18:48
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 423
Location: Belarus
redsock wrote:
Spectre is definitely not theoretical, their release included PoC code in both C and Javascript. IMO this is realistically only a real threat for the NodeJS/Javascript/Browser-JS/etc communities where running third-party/untrusted code is a regular practice (think of the npm ecosystem, haha, scary stuff). Spectre gives me access to _my own process' memory_, so if you can imagine being able to arbitrarily dump your own memory, well there you have it. In most cases, including all of my own, I already have access to my own memory in my running processes, which is why this isn't a concern. In the Javascript/NPM (and several others of course), where running other people's code in your process space (or in their PoC case, a browser running JS) you can see that being able to access the parent process memory could be a bad thing security-wise.

Meltdown however is an entirely more scarier thing IMO. I spent yesterday doing a preliminary once-over (since they haven't yet released PoC code for it). I'll summarise by saying: Meltdown gives an unprivileged user the ability to dump the entirety of physical RAM in a machine, bypassing ring0/ring3 protections.

In saying that, I wrote a test case for it and was unable to reproduce it thanks to my missing what they call a "precondition" that is required, which they suggest in a roundabout-way is that the kernel/target memory must reside in the L1 cache in order to circumvent the "race condition" between speculative execution and the privilege check and subsequent interrupt/error/fault. I am still working on it Smile

In summary, Meltdown is way way worse but I have yet to reproduce it...

Thanks for the post. Glad to see there are people who try to analyze the problem deeper (most people on the Internet don’t). I’ll add my five cents to the doubts. As far as I understood from what I’ve read, both cases are not really security vulnerabilities. I’d say, they’re just bugs.

Well, one definitely can read kernel-mode memory, but I haven’t seen any notices about writing there by means of the bugs. And, like you said, reading memory of your own process doesn’t give you much.

JS and other JIT stuff is arguable. If JIT lets one run arbitrary code accessing arbitrary addresses (basis for these attacks), that’s a JIT security vulnerability in the first place: JIT let you come into the flat, so there’s no need to blame floors of the flat that they let you see someone’s footsteps, you’re already on the other side of security boundary.

As for Meltdown, it is not that bad either. OK, you can dump all the physical memory, but you don’t have real control over what pages are present there. To have such control one at least needs write access to structure used for paging.

Reading the whole physical memory is possible without Meltdown and Spectre: one just needs to gain administrator privileges and there’re much easier ways relying on software bugs only, which is more reliable than trying to sneak into a small time window hoping something useful will be in RAM.

The bugs can definitely make some attacks easier but don’t really allow them on their own: one still needs quite strong preconditions (most of which are actual security vulnerabilities). So, I consider them overrated.
Post 07 Jan 2018, 13:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
I consider that browser JS reading memory to be a very serious problem. There are many things kept in kernel memory that you shouldn't be happy about anyone knowing. Encryption keys are the most prominent target, but also various buffers and whatnot that no website has any business knowing.

And some random code that you download shouldn't have access to other memory either. Not many people can, or do, audit the outgoing data connections so exfiltrating data is usually not a problem for any malicious program.
Post 07 Jan 2018, 16:29
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
DimonSoft wrote:
Reading the whole physical memory is possible without Meltdown and Spectre: one just needs to gain administrator privileges and there’re much easier ways relying on software bugs only, which is more reliable than trying to sneak into a small time window hoping something useful will be in RAM.

The bugs can definitely make some attacks easier but don’t really allow them on their own: one still needs quite strong preconditions (most of which are actual security vulnerabilities). So, I consider them overrated.
Spectre doesn't even rely on bugs, in fact it relies on stuff like array bound checks, which is considered "good" code practice. (I wonder if the bound instruction (32-bit only) would help here, if it wasn't so slow)

As for the administrator privileges, privilege escalation exploits are rarer and harder to exploit, usually they also take a lot of time to "warm up" which is noticeable. And they can be patched easily without any performance degradation.
Post 07 Jan 2018, 20:04
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 423
Location: Belarus
revolution wrote:
I consider that browser JS reading memory to be a very serious problem. There are many things kept in kernel memory that you shouldn't be happy about anyone knowing. Encryption keys are the most prominent target, but also various buffers and whatnot that no website has any business knowing.

And some random code that you download shouldn't have access to other memory either. Not many people can, or do, audit the outgoing data connections so exfiltrating data is usually not a problem for any malicious program.

But sensitive user data is still available in user-mode, since it sometimes needs to be displayed/edited. I do understand that stealing secret keys for asymmetric cypher-based stuff is terrible. In case you can tell the difference between an encryption key and some random piece of data. But can you really? And why do you use a cipher where keys are so easy to recognize?

And like I said, I can’t agree that JS case is about Meltdown and Spectre. Browser, in fact, gets source code in a managed language that normally doesn’t allow direct access to any particular address. If, after just-in-time compiling the code, we can reliably produce accesses to arbitrary places in memory, we’ve already lost even before the CPU bugs were discovered.

Furs wrote:
Spectre doesn't even rely on bugs, in fact it relies on stuff like array bound checks, which is considered "good" code practice. (I wonder if the bound instruction (32-bit only) would help here, if it wasn't so slow)

As for the administrator privileges, privilege escalation exploits are rarer and harder to exploit, usually they also take a lot of time to "warm up" which is noticeable. And they can be patched easily without any performance degradation.

AFAIK, the bound checks would not expose kernel memory without the bug(s) in speculative execution (I may have wrong info, will appreciate any links describing means to do that without speculative execution racing condition). Anyway, it doesn’t matter if bound checking or pie baking lets an attacker get in. What we really should worry about is what can an attacker do with it.

And yes, I’m aware that privilege escalation is harder to find and exploit and relies on exact OS/libraries versions more than this stuff. What I’m trying to say is that these CPU bugs (as described now) are not usable by themselves: even though you can read some sensitive info, certain preconditions are required and one still gains read-only access without control over what can really be read.

It is easy to blame a brick for falling on one’s head. And it may even be a serious bug in the Universe (fix would be to change its path when it approaches a head). But the practical question is: why would one store brick in a place where it can fall from.
Post 08 Jan 2018, 15:43
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1264
DimonSoft wrote:
And like I said, I can’t agree that JS case is about Meltdown and Spectre. Browser, in fact, gets source code in a managed language that normally doesn’t allow direct access to any particular address. If, after just-in-time compiling the code, we can reliably produce accesses to arbitrary places in memory, we’ve already lost even before the CPU bugs were discovered.
What? Any input (and in this case, script) can access anything, I mean, that's why we have input validation. Input can be literally anything and there's nothing you can do about it. However, you can indeed validate the input, which is proper security practice. The thing with Spectre is that it is this very input validation that can be exploited.

You haven't "lost" before the CPU "bugs" were discovered. The software correctly checks array bounds and does not allow invalid input, but Spectre can be used to work around this fact and read arbitrary memory by using the validation itself. Because the "check" is done with a branch and thus, speculative execution.

Are you saying validating input is a bad thing, or rather, we should not allow input whatsoever? Then getting online wouldn't be possible since e.g. even html needs to be validated. Anything interactive can be crafted to be "bad", that's why validation is important on anything untrusted. Rendering it as "bad input" and yet Spectre takes advantage of this fact. That's why it's so dangerous, it uses one of our security practice against itself.
Post 08 Jan 2018, 18:16
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.