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.

Branches are not where the bug is: speculative execution rollback is done wrong.

if(index from JS is within bounds of array)
{
  do stuff
}    

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

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?

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

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.

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

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

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.

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.

DimonSoft wrote:

There are three kinds of lies: lies, damned lies, and statistics.

Beware, you live in a reality that is a lie.

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.

Getting even half (on average) of a key is way better than just guessing (and then just guess the rest).

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.

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.

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.