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.

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.

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

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?

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.

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?

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.

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?

A new variant of the attack, remote instead of local, and showing how the speculative execution can be a vulnerability not only when combined with caching, but generally when it allows for detectable timing changes for whatever reason.
https://misc0110.net/web/files/netspectre.pdf

A new variant of the attack, remote instead of local, and showing how the speculative execution can be a vulnerability not only when combined with caching, but generally when it allows for detectable timing changes for whatever reason.
https://misc0110.net/web/files/netspectre.pdf

I hate such shitturity (sic!) research.

Quote:

As the difference in the response time is in the range of nanoseconds, the attacker needs to average over a large number of measurements to obtain the secret value with acceptable confidence.

The range of time for performing network access is in milliseconds (or even seconds for some Internet connections) range. And they’re trying to measure 10^6 smaller timings. A simple task switch at the attacker’s system (which happens at nearly random moments in time) would cause a larger difference in timing than what they’re looking for. Not even mentioning the effects of changing the amount of packets intermediate nodes have to process at the same time causing significant changes in network timings.

They’re basically calling John “The abstract” Smith by phone and measuring the time between the last digit entered and John answers. After doing this a lot of times they find the average time and if it is not 5 seconds but 5.5 seconds, they tell us that John had to run out of the toilet, write a PhD dissertation on the topic pretending they managed to guess what toilet paper John used and what smell did it have after being used.

Last edited by DimonSoft on 27 Jul 2018, 09:27; edited 1 time in total

I would say that we should be careful to not underestimate the power of statistics. When there are huge numbers of measurements involved it is possible to detect some things that on the surface seem undetectable (vide particle physics). Even if it does not work well in this particular case, I'd recommend not to judge too hastily.

I would say that we should be careful to not underestimate the power of statistics. When there are huge numbers of measurements involved it is possible to detect some things that on the surface seem undetectable (vide particle physics). Even if it does not work well in this particular case, I'd recommend not to judge too hastily.

There are three kinds of lies: lies, damned lies, and statistics. Particle physics talks about very specific processes with few relevant factors. In this case, I would even bet on it, a simple guessing strategy might be more successful in determining the actual bit values. The same applies to Meltdown/Spectre, although in those cases successful attacks are easier to perform.

The whole side-channel attack family seems like something stupid. Come on, guys, let’s measure changes in the voltage of our power source and explain it with another computer on the other side of the earth having a branch misprediction. Even if we know the reason for sure we can make nothing to fix that: each and every instruction might have its own power/time/etc. requirements which, when measured precisely, can let us write a debugger

P.S. Thanks for the link anyway. It will be useful for my lectures on the basics of computer security next year.

Nothing surprising. You might as well exist in my mind only. I might not have a physical body, it might be simulated by my mind.

Speaking about particle physics, they at least do not apply their statistics to a single particle, they basically just say that having a VERY large amount of VERY similar particles we can predict that most (but NOT all of them) will behave this or that way which can be observed as a particular high-level effect.

NetSpectre application of statistics says that having numbers of different orders of magnitude that are summed up randomly we can try to tell something about numbers of the smallest magnitude by averaging the sums. It’s like putting people and elephants on a platform that shows the weight, making them jump and dance, calculating the average value and then telling that a bee sat on the platform for a while.

Regardless of whether the statistics work out or not, the real solution at the moment (until new immune CPUs are designed) is to stop running unaudited code. So for most people that simply means no JS, problem solved.

There are three kinds of lies: lies, damned lies, and statistics. Particle physics talks about very specific processes with few relevant factors. In this case, I would even bet on it, a simple guessing strategy might be more successful in determining the actual bit values. The same applies to Meltdown/Spectre, although in those cases successful attacks are easier to perform.

I bet you still won't "guess" a correct cryptographic key for example, while it is quite plausible (even if super slow) with this attack. Nobody said it has to be 100% right or precise. Getting even half (on average) of a key is way better than just guessing (and then just guess the rest).

You can call it stupid or a joke but the fact is it can reveal such information that would be impossible for you to guess -- if not, then go ahead and guess the private key for a Bitcoin address with a lot of bitcoins, you'll have a real, massive reward on your hands if you think you can do it.

I bet you still won't "guess" a correct cryptographic key for example, while it is quite plausible (even if super slow) with this attack. Nobody said it has to be 100% right or precise. Getting even half (on average) of a key is way better than just guessing (and then just guess the rest).

You can call it stupid or a joke but the fact is it can reveal such information that would be impossible for you to guess -- if not, then go ahead and guess the private key for a Bitcoin address with a lot of bitcoins, you'll have a real, massive reward on your hands if you think you can do it.

Let me put it another way. Tomorrow at 10:00 I’ll choose a direction (left or right) and start moving 5 meters in that direction, a few times with 5 minute intervals. I’m absolutely sure you’re closer to my place than 5 * 10^6 meters. So, please, go ahead and find out by measuring the movement of the air around you (caused by my moves) what moves will I make. Use statistics and average calculations to decrease the impact of winds, buildings, etc. on the measurement results.

Almost every computer with an Intel chips dating back to 2011 are affected by the vulnerabilities. AMD and ARM chips are not said to be vulnerable like earlier side-channel attacks.

That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware.

Quote:

The safest workaround to prevent this extremely powerful attack is running trusted and untrusted applications on different physical machines.

If this is not feasible in given contexts, disabling Hyperthreading completely represents the safest mitigation. This does not, however, close the door on attacks on system call return paths that leak data from kernel space to user space.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum