51–60 of 294 posts
This is a great article on the subject and I like the clear explanation, with code examples on their fixes. I don’t think I will ever forget the line “we cannot trust branches”, it’s just amazing that such a fundamental part of the CPU was broken here.
Not that Spectre attacks are going to be easy to pull off, but it really makes you reconsider everything that you thought you could take for granted.
> All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me…
(Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)
One of the most brilliant features in the latest versions of Safari are per-website settings for ad blockers, notifications, location, etc. Between those two vulnerabilities and the general obnoxious useage of JS on websites, I’d love to see the addition of a per-website setting for JS. I would personally turn it off by default and only whitelist a handful of websites.
It's a bit fiddly, but you can set moderately sane defaults. Well, sort of. If websites themselves were far more sane, this would be far less a problem.
I'm starting to think naming multiple similar vulnerabilities by different names was a mistake. Every article I read I have to go back and remind myself while one was which.
> All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me…
Something I keep coming back to in all this is that maybe we should be surprised that it’s even possible to share a CPU between mutually untrusted programs, let alone do it in so many contexts. How do we stop his entire class of bugs? What is the Rust for CPU design?
Writing algorithms in parallel manner isn't as complicated as make to believe you, a lot can be rewritten based on cookbooks/patterns.
Intel developed a many-core CPU (72 CPU cores) called Xeon Phi: https://en.wikipedia.org/wiki/Xeon_Phi
Unfortunately they drifted of the target (instead of making it the successor of x86-64).
For Javascript engines, it would help if the offer an optional fallback "Javascript interpreter" instead of JIT. A JIT is basically at the moment insecure, especially when running untrusted code. The same goes for WebAssembly, let the user deactivate execution/support of it. Please allow end user to enable an alternative JS interpreter for high security things like online banking.
> All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me…
Doesn't Rust do all its type checking at compile time, not run-time? (Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)
> All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me…
> But Spectre could theoretically involve any branch that enforces security properties, like the branches used for type checks in JavaScriptCore.
I get the impression this is all referring to JIT'd JS, not to the C++ (or Rust etc.) code powering the underlying engine (where all typechecking is done at compile-time anyway). Of course having the JS engine written in Rust would still allow the same, but it's been known for a long time that Rust's typesystem can't do squat to verify the correctness of dynamically-generated code; it's part of the reason why Mozilla only bothered to kick off a rewrite of Gecko and not SpiderMonkey.
I'm really curious how SharedArrayBuffer can be used to create high-precision timers. I'm also wondering what's now broken due to SharedArrayBuffer being removed.
Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?
Gecko [0]: accurate to 20us
Edge [1]: accurate to 20us, with an additional 20us of noise
Chrome [2]: accurate to 100us (thanks mkeblx for finding this)
Safari [OP]: accurate to 1000us
[0] https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
[1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...
[2] https://chromium-review.googlesource.com/c/chromium/src/+/85...
Earlier quoted context omitted.
Doesn't Rust do all its type checking at compile time, not run-time? (Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)
If I'm reading this correctly, the issue isn't with the types of the language you wrote the Javascript engine in, but with Javascript's types. All major Javascript engines are written in C++, which also does all its type checking at compile-time.