I thought Google said the Chrome fix for Spectre (timing precision and shared array buffer) weren’t going in until end of January (as they said in the announcement at https://www.chromium.org/Home/chromium-security/ssca)
Thanks for the link, I hadn’t seen that.
I never thought it was an actual fix, but the lower-res timers were supposed to make the attacks much more difficult to execute. I guess not so much!
No, those are now. End of January are the V8 changes related to possible JIT-enabled exploits of Meltdown and Spectre.
Yes, as the article shows, there are lots of creative ways to employ to have high-resolution timers, some of them really hard to mitigate (like the “busy loop” thing). Of course, most require ideal conditions to actually work effectively, which might be tricky in a computer in normal operation, but take a reasonably “idle” computer and they become that much more dangerous.
This isn’t accurate today though, as the PDF was from… does it even have a date? Certainly not in the last, say, week:
In both Chrome and Webkit, the timer resolution is decreased by rounding the timestamp down to the nearest multiple of 5 µs
They are radically reducing precision, not a little bit, a lot:
This will decrease the resolution of the performance.now() timer from 5 microseconds (µs) to 20µs
As in, not microseconds of lost precision (depending on the browser) but MILLISECONDS. Orders of magnitude higher.
At the time it was written, the Tor browser had a timer resolution of 100ms, and they found better hidden timers there than in any of the other browsers they tried.
As long as the question is ‘which of these operations takes longer’ and not ‘how long does this operation take’, I can’t picture any invulnerable defense in the context of a system and programming environment which allows concurrent execution. (The article’s authors note that the former question is easier to answer in the presence of countermeasures, and coincidentally the one that’s more interesting for Spectre.)
Read the PDF. The “alternate” timers described there are still viable in most browsers (even the ones with mitigation) regardless of the “API” support, and at least one of them is nearly impossible to mitigate (though, since it’s easy to detect, there are ways to “mitigate” it).
Actually, one of the mitigations applied is actually because of the most precise alternate timing technique in that article, so you might want to take a second look.
Just a question from the total layman:
I have always stayed clear of putting my credit card info about anywhere, but one exception is Steam.
I am running Steam on a PC of which it is the entire purpose: I don’t do anything else on it, and I especially do not browse. But I can’t help but notice that Steam is running a version of Chrome inside, and I am assuming the store front in the client is just a web interface of sort. Is there reason to be more paranoid regarding Steam and those credit cards info?
Those conditions are now considerably less ideal with the latest anti-spectre timing resolution changes and branch defeating bounds checks they’ve added to the browser JS engines. It’s not a credible threat.
Is this something that will be fixed in the hardware of newer CPUs or just in newer generations of CPUs?
Spectre from all reports requires a rethink of CPU architecture, it could take awhile…
If at all, might just be something we need to learn to live with, assuming we still need as fast as possible hardware.
But AMD CPUs are not affected. I guess they just do things very differently.
Per the AMD web page, not quite, one of the issues is “not demonstrated on AMD processors to date”, which could certainly mean it’s immune.
AMD CPUs are vulnerable to some of the Spectre attacks, but not to Meltdown.
It’s been a long time since I’ve thought about chip design, but it doesn’t seem like a difficult problem to solve conceptually. What it boils down to is that processors need to enforce separation between cache used for speculative execution and cache used for execution known to be on the correct path. Unfortunately (though processor design is only barely in my wheelhouse, so I could be wrong about this in either direction), doing that seems to me to be either very hard or very slow, to the point that I’d bet the people whose job this actually is will come at it from a different direction entirely.
I don’t think so, no. Unless you are entering your credit card data each and every time, then Valve (or their payment service provider if they don’t do it themselves) is referencing your CC data their end and it would be pretty safe to assume they are mitigating with the various patches server-side.
If you are entering your data each time, then it will still require your own machine to have been compromised (in which case your problem is larger than Valve/Steam), or an attacker would need to be injecting malicious code into Steam (and if Valve was compromised in this regard, the attacker likely has lower hanging fruit in attacking Valve’s infrastructure than leveraging this exploit).
Well, timing resolution changes do little to prevent the issue, but branch defeating bounds checks do make any exploits extremely hard (I was not aware of JS engines implementing that as mitigation). That said, while it’s really hard, it’s not impossible, especially considering the complex JIT nature of modern scripting engines.
That said, as threats go, there are usually easier-to-exploit vulnerabilities around that attackers will most likely go for, so for patched browsers it might indeed not be a credible threat, at least for the time being. We’ll see.
I want a graphic of the total computing power on the world, I bet this event show in it like a spike going down.
Maybe the first time in our life that computing power has moved down instead of up.
Probably quite a few natural disasters and blackouts/brownouts did that too.