Incorrect. Same mitigations work against both, requires incredibly high JS timer precision to exploit.
Nope, meltdown isn’t dependent on timing like spectre. Protection from one attack doesn’t necessarily protect against the other two.
It does in this case, because it’s not a native code executable. The window of attack for Javascript in all cases is highly dependent on being able to read values from memory with very high timing precision.
TL;DR if you have a patched browser, you’re not vulnerable to any JavaScript based attack. I don’t think the Chrome patched browser is out until later in January though, not sure about the others.
If you run native code willy-nilly on your machine, you definitely are though.
My reading of the various articles and such indicates you’re wrong, but I lack the knowledge to argue further. Do you have anything to support that statement?
Since I can see you’re gonna keep replying over and over and over and over here, let me pre-empt you with the direct words from the WebKit (Apple) developers.
Meltdown means that userland code, such as JavaScript running in a web browser, can read kernel memory. Not all CPUs are affected by Meltdown and Meltdown is being mitigated by operating system changes. Mounting a Meltdown attack via JavaScript running in WebKit requires first bypassing branch-based security checks, like in the case of a Spectre attack. Therefore, Spectre mitigations that fix the branch problem also prevent an attacker from using WebKit as the starting point for Meltdown.
and
Meltdown allows userland code to read kernel memory. WebKit is indirectly affected by Meltdown because a Meltdown attack could be initiated using any kind of code execution, including JavaScript. However, the memory accesses used to perform Meltdown would be a violation of WebKit’s security model. Therefore, JavaScript-based Meltdown attacks must first use Spectre to get around WebKit’s security checks.
Trust me when I say, if you have a browser version with the reduced timer precision, the odds of anyone using JavaScript to do jack and shit are effectively nil.
Native code has no such timer limitations, and that is critical to all of this.
That specific text reads like it’s webkit-specific. So it would probably translate to blink, but probably not to gecko.
It’s not. It’s the same code. Everyone uses the same approaches.
Assuming they’re talking about the sandbox by “security checks”, the gecko sandbox implementation isn’t identical to webkit. Might it have the same effect? Maybe. But neither of us actually know.
Chrome and safari are looking pretty good though. So use one of them, Desslock.
We do in fact know. For example, look what Firefox did:
Specifically, in all release channels, starting with 57:
- The resolution of performance.now() will be reduced to 20µs.
- The SharedArrayBuffer feature is being disabled by default.
Now look what Webkit did:
WebKit’s response to Spectre is a two-tiered defense:
- WebKit has disabled SharedArrayBuffer and reduced timer precision.
- WebKit is transitioning to using branchless security checking in addition to branch-based security checking.
And here’s what Chrome says:
A high-precision timer makes it easier to observe side channels in the SSCA vulnerability. If your product offers high-precision timers that can be accessed by untrusted JavaScript or WebAssembly code, consider making these timers more coarse or adding jitter to them.
Oh look they are FUCKING. IDENTICAL. That’s surprising! I am shocked!
That’s the timing fix for Spectre, yes. Clearly all three browsers are protected against Spectre to a similar degree. Nobody said or implied otherwise.
The webkit dev said javascript meltdown attacks needed to use spectre to get around webkit’s security checks. What are those security checks? My assumption is their sandbox, but that’s just a guess.
Let’s read again, shall we?
Therefore, Spectre mitigations that fix the branch problem also prevent an attacker from using WebKit as the starting point for Meltdown.
Therefore, JavaScript-based Meltdown attacks must first use Spectre to get around WebKit’s security checks.
Ultra high precision timing is required for ANNNNYYYYYY OFFF THISSSSSSS
You might indeed be correct, but the text you posted does not specifically say that.
I no longer care. Believe what you want. The earth is flat. Robots will be coming to get us. I do not give a fuck.
Serenity now, bro!
I’m pretty sure looking at your computer screen makes you extra vulnerable so you better turn that off ASAP
Also, vaccines cause autism.
That’s what they say, yes.
Also, I would still patch. Gaming impact is minimal. Why risk it?
I mean, I am sure that the NSA is sitting on a version of it powered by whatever dark magic they have found or installed, but all known or even really short term theorized exploits that would be at a browser level are using the ability to discern the difference in timing of a memory vs cache fetch as the crucial component needed for it to work at a fundamental level.
I have not seen anything that would imply that the mitigations being put in place don’t work, however these is a lot of additional things that they are looking to do to hopefully be able to put the high resolution timing back in since it’s kind of useful and all…
Reducing performance.now() resolution is not a sufficient fix for the availability high-resolution timing. @rhamorim posted that article earlier, actually. (Thanks, Discourse!)