flat assembler
Message board for the users of flat assembler.

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

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
x64



Joined: 08 Jan 2018
Posts: 14
We people who live today will be remembered as the people who grew up in an age when everything was still maturing, every other day something leaked out from their private lives. In a hundred years people will look back at the "Dark Ages" when people grew up and leaked their private data all year long.
Post 08 Jan 2018, 22:44
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 258
Location: Belarus
Furs wrote:
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.

You seem to be missing the point. Conditional branching here is just a means to fool processor into executing an instruction that shouldn’t have been executed. But the instruction should try to access the memory you want to read later by accessing cache. Branches are not where the bug is: speculative execution rollback is done wrong.

You have JS code that (after JIT compilation) contains a branch that is predicted wrong. That’s normal situation. The source language doesn’t allow a programmer to control where a variable will be placed in memory. It doesn’t even have a notion of “memory address”, addresses are hidden behind so-called links and their values are not/should not be directly accessible to JS scripts. The problem is that somehow the JIT compiler lets an instruction following the branch access arbitrary memory location (control addresses that get cached). That is crossing security boundary in our case. You can cross even more security boundaries after that, but, like I said, you don’t gain really much by reading memory if everyone plays safe.

I don’t see how this can be read as “validating input is a bad thing”. On the contrary: it is lack of validation in the JIT that lets the source JS code be compiled into instructions accessing certain memory locations. So, it might be a security vulnerability in the JIT in the first place, since JITted code is not supposed to perform arbitrary memory accesses.
Post 09 Jan 2018, 05:53
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
DimonSoft wrote:
Branches are not where the bug is: speculative execution rollback is done wrong.
It's not wrong, they just never thought the cache itself would have to be rolled back. It doesn't change the CPU's normal behavior so it's not wrong, but timing can take advantage of it.

And how would you implement arrays in a JIT code without accessing memory? I don't understand what you are saying, sorry. Can you show some examples? Show an example of accessing an array in JS and compiled to JIT (simplistic example) how you would access such an array. Typically, accessing an array results in JIT like:
Code:
if(index from JS is within bounds of array) { do stuff }
which is 100% safe without Spectre.

Thing is in script you can send valid values over and over to train the predictor and then an invalid arbitrary value and it will think it's valid (speculative execution) and read memory arbitrarily. The CPU predicts it right and thinks it's within bounds so it does access the arbitrary memory outside the array. Of course this gets rolled back eventually since it's out of bounds (predicted wrong), but then that arbitrary memory (from same process, i.e. browser) is read into the cache and you can use timing attack on that info.

I don't see how you can make JIT code "safer" in this respect. You have to branch eventually. Obviously, reducing the time precision helps (and it's been done as a mitigation).
Post 09 Jan 2018, 14:48
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 283
Location: Australia
I was busy attending to other matters since my last post here, but they released the Meltdown PoC, my efforts based on their paper were within a few instructions of being correct haha.

Wow: https://github.com/IAIK/meltdown/.

_________________
2 Ton Digital - https://2ton.com.au/
Post 09 Jan 2018, 19:34
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2653
Location: dank orb
These vulnerabilities are also examples of how an AI could break out of it's sandbox on these processors.
Post 09 Jan 2018, 23:07
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
Can Spectre read kernel memory or memory of other users' processes? I find conflicting information online, and the proof of concept only shows how to read the current process' memory (which is not so bad, since it can be sandboxed).

I mean, I see Linux kernel and distros "pending" update on the kernel itself to mitigate Spectre... so I'm assuming it can? Or what? Confused
Post 10 Jan 2018, 14:59
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 258
Location: Belarus
Furs wrote:
DimonSoft wrote:
Branches are not where the bug is: speculative execution rollback is done wrong.
It's not wrong, they just never thought the cache itself would have to be rolled back. It doesn't change the CPU's normal behavior so it's not wrong, but timing can take advantage of it.

Imagine you’re a kid and your parents have explicitly disallowed you to open a box in the corner of their room. You’re curious and decide to take a look while they’re not at home. It turns out that they hide your Christmas gifts there—a toy car. You take it out of the box, play with it outside, then put it back to the box leaving it exactly the way it was. But you leave the car wheels dirty, and your parents may notice that.

Are you trying to say it’s not your fault because you just never thought you’d better clean the wheels? You didn’t break the car, everything looks like expected. Except the wheels.

The rollback is expected to restore cache states: code run with speculative execution enabled is required to produce the same effects as without, otherwise we would get different behaviour for the same program. That they didn’t think about it is not an excuse: if I didn’t think I should zero out memory pages before giving them to a process, that doesn’t mean I was right not doing so. After all, if the changes in cache used by Meltdown/Spectre were part of normal operation nobody would bother fixing this.

Furs wrote:
And how would you implement arrays in a JIT code without accessing memory? I don't understand what you are saying, sorry. Can you show some examples? Show an example of accessing an array in JS and compiled to JIT (simplistic example) how you would access such an array. Typically, accessing an array results in JIT like:
Code:
if(index from JS is within bounds of array) { do stuff }
which is 100% safe without Spectre.

Thing is in script you can send valid values over and over to train the predictor and then an invalid arbitrary value and it will think it's valid (speculative execution) and read memory arbitrarily. The CPU predicts it right and thinks it's within bounds so it does access the arbitrary memory outside the array. Of course this gets rolled back eventually since it's out of bounds (predicted wrong), but then that arbitrary memory (from same process, i.e. browser) is read into the cache and you can use timing attack on that info.

I don't see how you can make JIT code "safer" in this respect. You have to branch eventually. Obviously, reducing the time precision helps (and it's been done as a mitigation).

I got your point. Yes, I guess, in this case very little can be done during code generation phase. But don’t you think the generated code should have been put outside the browser process right at the moment when %BrowserDeveloper% changed their engine from interpreting to JITting? There’s even more interesting stuff in the user-mode memory of a browser: user credentials, passwords entered in the forms, etc.

Yes, CPU allows to read current process memory and that is a bug. But we already run trusted and untrusted code on the same side of security boundary. It is exactly like MS-DOS mentioned by Tomasz: all the scripts share the same address space.

Modern browsers create separate processes for separate tabs. If any of these browsers allows such an attack, it definitely has other vulnerabilities. Like storing sensitive data in shared memory or something?

Meltdown case is somewhat trickier, but still requires sensitive data to be paged-in while doesn’t let an attacker to control paging.

---

Once again: I don’t say it is not a bug, I don’t say it cannot be used to perform an attack. I’m just trying to say that, IMHO, Meltdown and Spectre are mostly useless in the absence of real security vulnerabilities, thus overrated.
Post 10 Jan 2018, 16:33
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2279
Location: Usono (aka, USA)
Furs wrote:
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?


Shocked

Wisdom 2:24 wrote:

But by the envy of the devil, death entered the world, and they who are allied with him experience it.


1 Peter 5:8-9 wrote:

Be sober and vigilant. Your opponent the devil is prowling around like a roaring lion looking for [someone] to devour. Resist him, steadfast in faith, knowing that your fellow believers throughout the world undergo the same sufferings.


Cool

Quote:

Kind of pissed right now. It's not like it's a common CPU, on the contrary.


I thought Haswell was extremely common??

I'm surprised anyone is surprised by this. All computers have flaws, all software has bugs. Is this really news? Do people really think they are 100% secure and too smart to make mistakes?

"Everything breaks." -- me
Post 12 Jan 2018, 01:51
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
I meant the Intel Xeon Haswell, which isn't really common. Razz
Post 12 Jan 2018, 13:11
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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 © 2004-2018, Tomasz Grysztar.

Powered by rwasa.