24 ms·

What Spectre and Meltdown Mean for WebKit

397 points by pizlonator 9y ago

ikeboy 9y ago
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.
- brianberns 9y ago
  Giving them similar names certainly wouldn't make it any easier to remember which one is which.
ENOTTY 9y ago
Isn't Intel and AMD shipping new fence instructions that prevent speculative execution from progressing beyond a certain point? Why doesn't Webkit use those?
- om2 9y ago
  The fence instruction that Intel recommends (lfence) is way slower than the techniques described here. We measured a 5x slowdown on Web Assembly trying to use it. Also we have been working on these mitigations since well before Intel made their suggestion.
  - br1 9y ago
    Have you considered arr[max(i, arr.len)] instead of AND?
    - tetromino_ 9y ago
      Max() is not a CPU instruction. It's an abstraction, a function that could be implemented either using a branch (which defeats the whole purpose) or, on some architectures, with something like cmovXX. Perhaps they wanted a solution that works on Arm, which I think doesn't have cmovXX. Or maybe Intel does speculation with cmovXX used on array index.
      - olliej 9y ago
        Cmov can speculate as well (it makes sense from a performance standpoint but that isn’t the same as secure ;) )
        om2 9y ago
        On some CPUs, cmov is known not to speculate, but in those cases it is apparently super slow.
- zzzcpan 9y ago
  I suspect fencing instructions are quite a bit slower than this, involve more work and don't even cover every CPU. Branchless bounds checking and type checking with masking and pointer poisoning is probably what we are going to see in other languages too.
- pizlonator 9y ago
  These mitigations are way cheaper than fences. For example, for WebAssembly, we measured that the fence instruction was a 5x regression. That’s nuts. Index masking is a rounding error by comparison.
NelsonMinar 9y ago
I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.
- zerkten 9y ago
  How will this last forever? Browsers seem like a relatively competitive and performance-oriented space.
- pizlonator 9y ago
  Our mitigations do not prevent branch prediction.
  - Game_Ender 9y ago
    You are removing branches, and adding slightly less clear code to do it. If this resulted in faster or cleaner code you would already be doing it. So the OP’s point holds: if these security holes are fixed at the CPU level, there will still be a generation of software compiled with these mitigation’s in and no way for a user on a newer CPU to disable them. EDIT: I just wanted to clarify here that I did not mean “all branches” just some of them, hence the name of the technique which is “branchless security” (which is a really good piece of engineering). The frustration is basically we have to bake in CPU model specific mitigation’s into binaries. You can of course patch it out, but the affected CPUs will in theory be in the wild for a long time to come even once corrected ones are released.
    - om2 9y ago
      The mitigations are largely in code produced by the JIT. It's not hard to patch the JIT's codgen to back this out (perhaps even based on current CPU) if it becomes unnecessary. It would be nice if CPU architectures never had this fundamental vulnerability, but they do. So this seems like the best response for the reality we actually live in.
bangonkeyboard 9y ago
What is the reasoning behind reusing version numbers?
- js2 9y ago
  Apple does this sometimes for macOS. It's probably because it's an application update, not an OS update (so OS patch version does not change), and doesn't require a reboot.
  - hamandcheese 9y ago
    This doesn’t explain why they kept Safari at the same version number.
    - js2 9y ago
      Oh you're right. Specifically, they kept the CFBundleShortVersionString the same, but updated the CFBundleVersion. My guess is that updating CFBundleShortVersionString is a marketing decision. Maybe Apple is waiting till all the WebKit fixes related to Spectre/Meltdown are available before updating it?
      - jurip 9y ago
        Also various Apple systems define CFBundleShortVersionString to be of the format A.B.C, no fourth element allowed. macOS versioning is still stuck with 10 as the A, B identifies the major release and C is the point release that is effectively also marketing driven. With iOS the first number is used for the major releases so C is available for bug fixes.
username223 9y ago
> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't type check. It's that the people running it don't consciously install it, the people distributing it don't know or care what it is, and the people writing it are often adversaries far more sophisticated than the people running it.
- EgoIncarnate 9y ago
  Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something, but that is a long way off. As for relying on users ability to determine what code is safe to download... It's not like users can be relied on to do the right thing all the time even without javascript. People respond to phishing attacks, download executables sent to their email, reuse passwords... I think a sandbox is a better solution than relying on users to understand what code is trustworthy and what isn't.
  - username223 9y ago
    > The web by and large requires javascript, and it's not likely to change. While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting close to a situation where average people recognize that millisecond auctions to run arbitrary code on their machines are a bad idea, and those people also have the tools to say "no." Hope springs internal...
Game_Ender 9y ago
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.
- syncsynchalt 9y ago
  I've been explaining to friends that Spectre is like discovering that ESP exists. 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.
  - om2 9y ago
    The scary thing is that without mitigations, it is shockingly easy to pull off. WebKit engineers made multiple fully working exploits internally and we would be hard pressed to do that for other kinds of vulnerabilities. Building full exploits out of your run of the mill use-after-free bug is much harder and requires specific expertise. Fortunately these mitigations make it way harder.
stcredzero 9y ago
A lot of game-related media has reported that a lot of games are largely unaffected by Spectre and Meltdown. My impression is that the most common result is "about 3%." (With some notable exceptions, however.) Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?
- alkonaut 9y ago
  The performance issues come from security mitigations when entering/exiting the kernel during syscalls. So I/O heavy workloads such as databases will suffer, whereas heavy compute-oriented tasks such as games should be mostly OK. This is expected. There is nothing any company can do to "take advantage" of the fact that games are cpu/gpu bound in order to mitigate new performance issues in e.g. databases.
  - SquareWheel 9y ago
    Exactly. Though it may encourage different performance best practices now that syscalls are considered more expensive.
Abishek_Muthian 9y ago
Good work WebKit team in putting this together, it's just as good as Raspberry Pi's note on why it isn't affected by Spectre & Meltdown - https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... Of-course here, the mitigation are being detailed as well.
TheCoreh 9y ago
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?
- skygazer 9y ago
  In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.
- bsimpson 9y ago
  It's surprising to me that there are such various levels of coarseness each browser vendor chose: 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-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e... [2] https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
  - mkeblx 9y ago
    Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
- flohofwoe 9y ago
  1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games to break :/
tasty_freeze 9y ago
With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction. The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.
- pizlonator 9y ago
  The problem that JSC is dealing with is that Spectre allows untrusted JS code to read things from the memory of the process that runs it. We don't want to allow that, but I don't think your proposed solution would fix it.
  - gpderetta 9y ago
    If browsers are careful not to put any sensitive information in the same process that is executing JS code, sandboxing could work. This seems a sensible thing anyway as it would mitigate other attacks as well. Allocating one process for JS-using webpage is expensive though.
    - om2 9y ago
      Chrome is working towards something like this with Site Isolation, and it’s a good idea. Unfortunately it’s not a complete defense. First, web pages can load cross origin resources, and that may be enough to get data or a cookie into the attacker’s web process. Second, some risks of this attack (e.g. ASLR bypass) don’t require any data from another origin to be in process to be dangerous.
      - gpderetta 9y ago
        > web pages can load cross origin resources I know nothing about web technologies, but maybe this is something we should stop doing, at least for any executable resource? This would prevent JS ads I guess, so win/win? > Second, some risks of this attack (e.g. ASLR bypass) don’t require any data from another origin to be in process to be dangerous. yes, ASLR seems to be busted.
ams6110 9y ago
> 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 to get out of this business.
- pizlonator 9y ago
  Right, programming-language-based security mechanisms that rely on emitting runtime checks are broken and you need something like index masking or pointer poisoning to fix them. Rust could use those fixes as well.
  - iainmerrick 9y ago
    Why does Rust need those? Those are things you need when running untrusted code in a sandbox. Is there a scenario where Rust is used that way? There's WASM, but in that case the extra checks need to be applied at the WASM level, not the Rust level.
- josephg 9y ago
  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?
  - 6nf 9y ago
    CPUs tend to have multiple cores these days, would it be possible to assign (in software) all kernal space work to one or more dedicated cores to mitigate some of the risks?
    - politician 9y ago
      Yes, well, close. > Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20] https://en.wikipedia.org/wiki/Translation_lookaside_buffer#PCID https://en.wikipedia.org/wiki/Translation_lookaside_buffer#P... HN discussion: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349
bradgessler 9y ago
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.
- DamonHD 9y ago
  This is what I already get with FF + NoScript. And yes, I am bored by sites that I visit for the first time that will not show me any meaningful content until I enable layer upon layer of JS. Just not necessary, nor is it safe.
  - pmontra 9y ago
    Sometimes you can open the developer tools and hack the CSS, because some of those sites hide content with a display: none unless some JavaScript removes it. If it's a site you often navigate to, there are addons like Stylus that can make those changes permanent.
  - duozerk 9y ago
    Same here (with noscript as well). Although I'll say it's hard to blame web developers for not considering the case where JS is disabled beyond a simple "you need Javascript to see this page" message (though even that tends to be the exception, not the rule), because noscript/umatrix users are probably in the low, low minority.
- dredmorbius 9y ago
  uMatrix, for everyone else. 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.
- rickycook 9y ago
  similar to noscript, there’s “JS Blocker” for Safari. it’s truly an excellent extension; significantly more powerful than noscript because it allows hugely customisable rules for loading only some scripts on some pages (eg https and *.cloudfront.com when loading console.aws.amazon.com), rules about canvas usage, XHR requests and a whole lot of other things. it’s the honestly the only reason i haven’t moved back to firefox, because by comparison noscript is just SO awful! http://jsblocker.toggleable.com/home http://jsblocker.toggleable.com/home
80x25 9y ago
These mitigations feel like a half measure. To quote the Spectre paper: "Even code that contains no conditional branches can potentially be at risk." "long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform." It seems too early to declare Spectre class attacks mitigated by the mechanisms presented in the OP.
- pizlonator 9y ago
  Maybe more than half. ;-) I think that the branch aspect of Spectre is the thing that WebKit is most affected by.
- EgoIncarnate 9y ago
  I don't think anyone is claiming this is solved. Mitigations are by definition a half measure. "Mitigate (verb): make less severe, serious, or painful."
- WillReplyfFood 9y ago
  Translated this basically means- for real security to exist, the chip has to be open source down to the layout. This will not happen. So basically, the interest of the one outweighing the interests of the many, results in the many suffering for what exactly?
  - dingo_bat 9y ago
    > open source down to the layout. I don't see what open source has got to do with any of this.
    - vog 9y ago
      More security experts would be encouraged to have a look at the design and to find flaws early on. Of course, we all know that this doesn't always happen, see OpenSSL. However, once a major incident (Heartbleed) happened, they did: Many more OpenSSL issues were found and fixed, forks with different trade-offs came into place. For example, LibreSSL traded backwards compatibility with ancient systems for a smaller code base and increased security. Since CPU designs are not Open Source, and on top of that flooded with patents, nothing like that will happen in this space. Intel and AMD are on their own, rather than having their design checked by a motivated international research community.
eridius 9y ago
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.
- indexerror 9y ago
  From page 10-11 of [1]: > A shared resource provides a way to build a real counting thread with a negligible overhead compared to a message passing approach. This already raised concerns with respect to the creation of a high-resolution clock [19]. In this method, one worker continuously increments the value of the buffer without checking for any events on the event queue. The main thread simply reads the current value from the shared buffer and uses it as a high-resolution timestamp. [1] https://gruss.cc/files/fantastictimers.pdf https://gruss.cc/files/fantastictimers.pdf
- syncsynchalt 9y ago
  By running a worker thread in a counting loop.
- Laremere 9y ago
  My understanding is: Have a web workers continuously increase a number, and save it to the SharedArrayBuffer. As long as the web worker is running, you have a steadily (enough) increasing timer that can be accessed by any other thread. It's not as precise, so relying on it makes things harder, but still usable.
roca 9y ago
I see how this addresses some examples of Spectre, and it's clever (hi Filip!) and probably worth doing. However, not all possible Spectre-related vulnerabilities involve type confusion. E.g. imagine if we had JS code that does let x = bigArray[iframeElem.contentWindow.someProperty]; Conceivably that could get compiled to some mix of JIT code and C++ that does if (iframeElemOrigin == selfDocumentOrigin) { index = ... get someProperty ... x = bigArray[index]; } else { ... error ... } and speculative execution could let the property value leak into the cache. So I'm not optimistic about the prospects for fully automating defenses against Spectre without hardware fixes :-(.
- om2 9y ago
  We assume no if statements that implement a security check are safe without something. It’s not just bounds checks and type checks. Origin checks are a special case worth considering. I am not sure what you describe would be exploitable in practice (reasons too long to fit in this margin) but worth looking into.
- pizlonator 9y ago
  Hi Robert! It’s been a while! :-) Oooh that’s a good catch. I agree that pointer poisoning and index masking don’t handle this case. Unless the pointer to the data structure being accessed (bigArray or whatever) is poisoned with a function of origin. Maybe that’s the way to do it. I am still optimistic about this. It’s going to be a lot of work and there will be surprises but then that’s always true when writing software.
cm2187 9y ago
I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc). This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location. [edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.
- duozerk 9y ago
  Unless you're considering client-side encryption, I don't think webmails qualify either (squirrelmail, for example, works pretty well without JS).
  - littlestymaar 9y ago
    Indeed because auto-complete of recipient address from my contacts is useless, right ? Same could be said for retrieving new emails without reloading the page I guess … Had JavaScript not existed, the web would be dead a long time ago already.
    - duozerk 9y ago
      Both good points (although the second one could be handled through a meta refresh I guess). But I'd like to point out we were discussing where javascript is absolutely needed, not where it's convenient.
thedonkeycometh 9y ago
"High Sierra 10.13.2 Supplemental Update. This reuses the 10.13.2 version number. " tsk tsk
fpoling 9y ago
It is not clear from the article how WebKit avoids changing semantics with array index masking. In JS out-of-bounds access should return undefined, not a random element of the array. To preserve that a branch still has to be made.
- bennofs 9y ago
  If you combine index masking with a branch that should still be Ok. For example, if you do `if(idx > arrayLength) return undefined else array[idx & mask]` then the CPU can only predict "return undefined" or "array[idx & mask]", none of which can cause any harm.
  - fpoling 9y ago
    Does that imply that WebKit always allocate by power of two and a script cannot read the memory for unrelated allocation between the array length and the nearest 2n?
    - iainmerrick 9y ago
      No, it means attacks are still possible in the memory region just after the buffer, when it's smaller than the next power of two. Not ideal but it's better than nothing.
deleted 9y ago
[deleted]
bakery2k 9y ago
Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca https://www.chromium.org/Home/chromium-security/ssca [2] https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [3] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...
- UncleEntity 9y ago
  > Or are these other VMs not susceptible to this form of attack? I think the main difference is all the other dynamic languages don't let someone do a driveby attack, you have to download the code and run it as opposed to clicking a link and having who knows what appear.
  - swinglock 9y ago
    Actually it's not entirely exotic for games to use Lua in a manner that's comparable to JavaScript in browsers. Connecting to a server could instruct the client to download a custom map that embeds code or download and execute sandboxed code alone by design.
- pizlonator 9y ago
  > Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? Yes. > What about the JVM and Microsoft's CLR? Yes.
  - deleted 9y ago
    [deleted]
  - bakery2k 9y ago
fpoling 9y ago
From the patches it seems that the write operation to the array is also protected with masking. What is the reason for it? If due to a bug unrelated to Spectre a JS code could trigger a write beyond the allocated memory, restricting writes to the next power of two just slightly complicates the attacks. This is very different from the reading situation.
- olliej 9y ago
  The masking is done in addition to bounds checks, not instead of, so no it isn’t adding a mechanism to write out of bounds - the masking is purely to limit the upper bounds of speculative load distance. As far as the attack: writing to memory pulls the effected page into the cache just as a read does
0x7f 9y ago
I don't understand why they say Spectre can control branching in WebKit. Spectre is an information leak attack, it doesn't allow to modify memory. I could allow to find x in `is x == valueToCheck`. But if this is possible, even before Spectre it's a security issue, it's only harder to guess, and Javascript code should not be allowed to control `x`.
- 0x7f 9y ago
  I think this part is misleading => "Spectre means that an attacker can control branches, so branches alone are no longer adequate for enforcing security properties." I think they meant "Spectre means an that attacker can ABUSE branches", and in that they are right.
  - pizlonator 9y ago
    This is clarified later: “Spectre means that branches are no longer sufficient for enforcing the security properties of read operations in WebKit.“ It’s totally true that Spectre allows attackers to control reads, but when they do this, they enter a non-destructive execution mode. They can read but anything they write is thrown away. (To our knowledge, lol.)
    - 0x7f 9y ago
      Thank you for clarifying, that what I thought. Still I find that the article is not clear enough on this point, I fell that some people will read this as "OMG they can control execution remotely, this the apocalypse". I mean to an extent yes, but the results are dropped like you said and the main execution path shouldn't be affected. It only facilitate information leaks AFAIK.
deleted 9y ago
[deleted]

397 points by pizlonator 9y ago

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.

brianberns 9y ago
Giving them similar names certainly wouldn't make it any easier to remember which one is which.

ENOTTY 9y ago

Isn't Intel and AMD shipping new fence instructions that prevent speculative execution from progressing beyond a certain point? Why doesn't Webkit use those?

om2 9y ago
The fence instruction that Intel recommends (lfence) is way slower than the techniques described here. We measured a 5x slowdown on Web Assembly trying to use it. Also we have been working on these mitigations since well before Intel made their suggestion.
- br1 9y ago
  Have you considered arr[max(i, arr.len)] instead of AND?
  - tetromino_ 9y ago
    Max() is not a CPU instruction. It's an abstraction, a function that could be implemented either using a branch (which defeats the whole purpose) or, on some architectures, with something like cmovXX. Perhaps they wanted a solution that works on Arm, which I think doesn't have cmovXX. Or maybe Intel does speculation with cmovXX used on array index.
    - olliej 9y ago
      Cmov can speculate as well (it makes sense from a performance standpoint but that isn’t the same as secure ;) )
      - om2 9y ago
        On some CPUs, cmov is known not to speculate, but in those cases it is apparently super slow.
zzzcpan 9y ago
I suspect fencing instructions are quite a bit slower than this, involve more work and don't even cover every CPU. Branchless bounds checking and type checking with masking and pointer poisoning is probably what we are going to see in other languages too.
pizlonator 9y ago
These mitigations are way cheaper than fences. For example, for WebAssembly, we measured that the fence instruction was a 5x regression. That’s nuts. Index masking is a rounding error by comparison.

NelsonMinar 9y ago

I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.

zerkten 9y ago
How will this last forever? Browsers seem like a relatively competitive and performance-oriented space.
pizlonator 9y ago
Our mitigations do not prevent branch prediction.
- Game_Ender 9y ago
  You are removing branches, and adding slightly less clear code to do it. If this resulted in faster or cleaner code you would already be doing it. So the OP’s point holds: if these security holes are fixed at the CPU level, there will still be a generation of software compiled with these mitigation’s in and no way for a user on a newer CPU to disable them. EDIT: I just wanted to clarify here that I did not mean “all branches” just some of them, hence the name of the technique which is “branchless security” (which is a really good piece of engineering). The frustration is basically we have to bake in CPU model specific mitigation’s into binaries. You can of course patch it out, but the affected CPUs will in theory be in the wild for a long time to come even once corrected ones are released.
  - om2 9y ago
    The mitigations are largely in code produced by the JIT. It's not hard to patch the JIT's codgen to back this out (perhaps even based on current CPU) if it becomes unnecessary. It would be nice if CPU architectures never had this fundamental vulnerability, but they do. So this seems like the best response for the reality we actually live in.

bangonkeyboard 9y ago

What is the reasoning behind reusing version numbers?

js2 9y ago
Apple does this sometimes for macOS. It's probably because it's an application update, not an OS update (so OS patch version does not change), and doesn't require a reboot.
- hamandcheese 9y ago
  This doesn’t explain why they kept Safari at the same version number.
  - js2 9y ago
    Oh you're right. Specifically, they kept the CFBundleShortVersionString the same, but updated the CFBundleVersion. My guess is that updating CFBundleShortVersionString is a marketing decision. Maybe Apple is waiting till all the WebKit fixes related to Spectre/Meltdown are available before updating it?
    - jurip 9y ago
      Also various Apple systems define CFBundleShortVersionString to be of the format A.B.C, no fourth element allowed. macOS versioning is still stuck with 10 as the A, B identifies the major release and C is the point release that is effectively also marketing driven. With iOS the first number is used for the major releases so C is available for bug fixes.

username223 9y ago

> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't type check. It's that the people running it don't consciously install it, the people distributing it don't know or care what it is, and the people writing it are often adversaries far more sophisticated than the people running it.

EgoIncarnate 9y ago
Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something, but that is a long way off. As for relying on users ability to determine what code is safe to download... It's not like users can be relied on to do the right thing all the time even without javascript. People respond to phishing attacks, download executables sent to their email, reuse passwords... I think a sandbox is a better solution than relying on users to understand what code is trustworthy and what isn't.
- username223 9y ago
  > The web by and large requires javascript, and it's not likely to change. While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting close to a situation where average people recognize that millisecond auctions to run arbitrary code on their machines are a bad idea, and those people also have the tools to say "no." Hope springs internal...

Game_Ender 9y ago

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.

syncsynchalt 9y ago
I've been explaining to friends that Spectre is like discovering that ESP exists. 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.
- om2 9y ago
  The scary thing is that without mitigations, it is shockingly easy to pull off. WebKit engineers made multiple fully working exploits internally and we would be hard pressed to do that for other kinds of vulnerabilities. Building full exploits out of your run of the mill use-after-free bug is much harder and requires specific expertise. Fortunately these mitigations make it way harder.

stcredzero 9y ago

A lot of game-related media has reported that a lot of games are largely unaffected by Spectre and Meltdown. My impression is that the most common result is "about 3%." (With some notable exceptions, however.) Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?

alkonaut 9y ago
The performance issues come from security mitigations when entering/exiting the kernel during syscalls. So I/O heavy workloads such as databases will suffer, whereas heavy compute-oriented tasks such as games should be mostly OK. This is expected. There is nothing any company can do to "take advantage" of the fact that games are cpu/gpu bound in order to mitigate new performance issues in e.g. databases.
- SquareWheel 9y ago
  Exactly. Though it may encourage different performance best practices now that syscalls are considered more expensive.

Abishek_Muthian 9y ago

Good work WebKit team in putting this together, it's just as good as Raspberry Pi's note on why it isn't affected by Spectre & Meltdown - https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... Of-course here, the mitigation are being detailed as well.

TheCoreh 9y ago

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?

skygazer 9y ago
In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.
bsimpson 9y ago
It's surprising to me that there are such various levels of coarseness each browser vendor chose: 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-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e... [2] https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
- mkeblx 9y ago
  Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/853505 https://chromium-review.googlesource.com/c/chromium/src/+/85...
flohofwoe 9y ago
1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games to break :/

tasty_freeze 9y ago

With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction. The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.

pizlonator 9y ago
The problem that JSC is dealing with is that Spectre allows untrusted JS code to read things from the memory of the process that runs it. We don't want to allow that, but I don't think your proposed solution would fix it.
- gpderetta 9y ago
  If browsers are careful not to put any sensitive information in the same process that is executing JS code, sandboxing could work. This seems a sensible thing anyway as it would mitigate other attacks as well. Allocating one process for JS-using webpage is expensive though.
  - om2 9y ago
    Chrome is working towards something like this with Site Isolation, and it’s a good idea. Unfortunately it’s not a complete defense. First, web pages can load cross origin resources, and that may be enough to get data or a cookie into the attacker’s web process. Second, some risks of this attack (e.g. ASLR bypass) don’t require any data from another origin to be in process to be dangerous.
    - gpderetta 9y ago
      > web pages can load cross origin resources I know nothing about web technologies, but maybe this is something we should stop doing, at least for any executable resource? This would prevent JS ads I guess, so win/win? > Second, some risks of this attack (e.g. ASLR bypass) don’t require any data from another origin to be in process to be dangerous. yes, ASLR seems to be busted.

ams6110 9y ago

> 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 to get out of this business.

pizlonator 9y ago
Right, programming-language-based security mechanisms that rely on emitting runtime checks are broken and you need something like index masking or pointer poisoning to fix them. Rust could use those fixes as well.
- iainmerrick 9y ago
  Why does Rust need those? Those are things you need when running untrusted code in a sandbox. Is there a scenario where Rust is used that way? There's WASM, but in that case the extra checks need to be applied at the WASM level, not the Rust level.
josephg 9y ago
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?
- 6nf 9y ago
  CPUs tend to have multiple cores these days, would it be possible to assign (in software) all kernal space work to one or more dedicated cores to mitigate some of the risks?
  - politician 9y ago
    Yes, well, close. > Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20] https://en.wikipedia.org/wiki/Translation_lookaside_buffer#PCID https://en.wikipedia.org/wiki/Translation_lookaside_buffer#P... HN discussion: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349

bradgessler 9y ago

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.

DamonHD 9y ago
This is what I already get with FF + NoScript. And yes, I am bored by sites that I visit for the first time that will not show me any meaningful content until I enable layer upon layer of JS. Just not necessary, nor is it safe.
- pmontra 9y ago
  Sometimes you can open the developer tools and hack the CSS, because some of those sites hide content with a display: none unless some JavaScript removes it. If it's a site you often navigate to, there are addons like Stylus that can make those changes permanent.
- duozerk 9y ago
  Same here (with noscript as well). Although I'll say it's hard to blame web developers for not considering the case where JS is disabled beyond a simple "you need Javascript to see this page" message (though even that tends to be the exception, not the rule), because noscript/umatrix users are probably in the low, low minority.
dredmorbius 9y ago
uMatrix, for everyone else. 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.
rickycook 9y ago
similar to noscript, there’s “JS Blocker” for Safari. it’s truly an excellent extension; significantly more powerful than noscript because it allows hugely customisable rules for loading only some scripts on some pages (eg https and *.cloudfront.com when loading console.aws.amazon.com), rules about canvas usage, XHR requests and a whole lot of other things. it’s the honestly the only reason i haven’t moved back to firefox, because by comparison noscript is just SO awful! http://jsblocker.toggleable.com/home http://jsblocker.toggleable.com/home

80x25 9y ago

These mitigations feel like a half measure. To quote the Spectre paper: "Even code that contains no conditional branches can potentially be at risk." "long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform." It seems too early to declare Spectre class attacks mitigated by the mechanisms presented in the OP.

pizlonator 9y ago
Maybe more than half. ;-) I think that the branch aspect of Spectre is the thing that WebKit is most affected by.
EgoIncarnate 9y ago
I don't think anyone is claiming this is solved. Mitigations are by definition a half measure. "Mitigate (verb): make less severe, serious, or painful."
WillReplyfFood 9y ago
Translated this basically means- for real security to exist, the chip has to be open source down to the layout. This will not happen. So basically, the interest of the one outweighing the interests of the many, results in the many suffering for what exactly?
- dingo_bat 9y ago
  > open source down to the layout. I don't see what open source has got to do with any of this.
  - vog 9y ago
    More security experts would be encouraged to have a look at the design and to find flaws early on. Of course, we all know that this doesn't always happen, see OpenSSL. However, once a major incident (Heartbleed) happened, they did: Many more OpenSSL issues were found and fixed, forks with different trade-offs came into place. For example, LibreSSL traded backwards compatibility with ancient systems for a smaller code base and increased security. Since CPU designs are not Open Source, and on top of that flooded with patents, nothing like that will happen in this space. Intel and AMD are on their own, rather than having their design checked by a motivated international research community.

eridius 9y ago

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.

indexerror 9y ago
From page 10-11 of [1]: > A shared resource provides a way to build a real counting thread with a negligible overhead compared to a message passing approach. This already raised concerns with respect to the creation of a high-resolution clock [19]. In this method, one worker continuously increments the value of the buffer without checking for any events on the event queue. The main thread simply reads the current value from the shared buffer and uses it as a high-resolution timestamp. [1] https://gruss.cc/files/fantastictimers.pdf https://gruss.cc/files/fantastictimers.pdf
syncsynchalt 9y ago
By running a worker thread in a counting loop.
Laremere 9y ago
My understanding is: Have a web workers continuously increase a number, and save it to the SharedArrayBuffer. As long as the web worker is running, you have a steadily (enough) increasing timer that can be accessed by any other thread. It's not as precise, so relying on it makes things harder, but still usable.

roca 9y ago

I see how this addresses some examples of Spectre, and it's clever (hi Filip!) and probably worth doing. However, not all possible Spectre-related vulnerabilities involve type confusion. E.g. imagine if we had JS code that does let x = bigArray[iframeElem.contentWindow.someProperty]; Conceivably that could get compiled to some mix of JIT code and C++ that does if (iframeElemOrigin == selfDocumentOrigin) { index = ... get someProperty ... x = bigArray[index]; } else { ... error ... } and speculative execution could let the property value leak into the cache. So I'm not optimistic about the prospects for fully automating defenses against Spectre without hardware fixes :-(.

om2 9y ago
We assume no if statements that implement a security check are safe without something. It’s not just bounds checks and type checks. Origin checks are a special case worth considering. I am not sure what you describe would be exploitable in practice (reasons too long to fit in this margin) but worth looking into.
pizlonator 9y ago
Hi Robert! It’s been a while! :-) Oooh that’s a good catch. I agree that pointer poisoning and index masking don’t handle this case. Unless the pointer to the data structure being accessed (bigArray or whatever) is poisoned with a function of origin. Maybe that’s the way to do it. I am still optimistic about this. It’s going to be a lot of work and there will be surprises but then that’s always true when writing software.

cm2187 9y ago

I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc). This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location. [edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.

duozerk 9y ago
Unless you're considering client-side encryption, I don't think webmails qualify either (squirrelmail, for example, works pretty well without JS).
- littlestymaar 9y ago
  Indeed because auto-complete of recipient address from my contacts is useless, right ? Same could be said for retrieving new emails without reloading the page I guess … Had JavaScript not existed, the web would be dead a long time ago already.
  - duozerk 9y ago
    Both good points (although the second one could be handled through a meta refresh I guess). But I'd like to point out we were discussing where javascript is absolutely needed, not where it's convenient.

thedonkeycometh 9y ago

"High Sierra 10.13.2 Supplemental Update. This reuses the 10.13.2 version number. " tsk tsk

fpoling 9y ago

It is not clear from the article how WebKit avoids changing semantics with array index masking. In JS out-of-bounds access should return undefined, not a random element of the array. To preserve that a branch still has to be made.

bennofs 9y ago
If you combine index masking with a branch that should still be Ok. For example, if you do `if(idx > arrayLength) return undefined else array[idx & mask]` then the CPU can only predict "return undefined" or "array[idx & mask]", none of which can cause any harm.
- fpoling 9y ago
  Does that imply that WebKit always allocate by power of two and a script cannot read the memory for unrelated allocation between the array length and the nearest 2n?
  - iainmerrick 9y ago
    No, it means attacks are still possible in the memory region just after the buffer, when it's smaller than the next power of two. Not ideal but it's better than nothing.

deleted 9y ago

[deleted]

bakery2k 9y ago

Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca https://www.chromium.org/Home/chromium-security/ssca [2] https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... [3] https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...

UncleEntity 9y ago
> Or are these other VMs not susceptible to this form of attack? I think the main difference is all the other dynamic languages don't let someone do a driveby attack, you have to download the code and run it as opposed to clicking a link and having who knows what appear.
- swinglock 9y ago
  Actually it's not entirely exotic for games to use Lua in a manner that's comparable to JavaScript in browsers. Connecting to a server could instruct the client to download a custom map that embeds code or download and execute sandboxed code alone by design.
pizlonator 9y ago
> Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? Yes. > What about the JVM and Microsoft's CLR? Yes.
- deleted 9y ago
  [deleted]
- bakery2k 9y ago

fpoling 9y ago

From the patches it seems that the write operation to the array is also protected with masking. What is the reason for it? If due to a bug unrelated to Spectre a JS code could trigger a write beyond the allocated memory, restricting writes to the next power of two just slightly complicates the attacks. This is very different from the reading situation.

olliej 9y ago
The masking is done in addition to bounds checks, not instead of, so no it isn’t adding a mechanism to write out of bounds - the masking is purely to limit the upper bounds of speculative load distance. As far as the attack: writing to memory pulls the effected page into the cache just as a read does

0x7f 9y ago

I don't understand why they say Spectre can control branching in WebKit. Spectre is an information leak attack, it doesn't allow to modify memory. I could allow to find x in `is x == valueToCheck`. But if this is possible, even before Spectre it's a security issue, it's only harder to guess, and Javascript code should not be allowed to control `x`.

0x7f 9y ago
I think this part is misleading => "Spectre means that an attacker can control branches, so branches alone are no longer adequate for enforcing security properties." I think they meant "Spectre means an that attacker can ABUSE branches", and in that they are right.
- pizlonator 9y ago
  This is clarified later: “Spectre means that branches are no longer sufficient for enforcing the security properties of read operations in WebKit.“ It’s totally true that Spectre allows attackers to control reads, but when they do this, they enter a non-destructive execution mode. They can read but anything they write is thrown away. (To our knowledge, lol.)
  - 0x7f 9y ago
    Thank you for clarifying, that what I thought. Still I find that the article is not clear enough on this point, I fell that some people will read this as "OMG they can control execution remotely, this the apocalypse". I mean to an extent yes, but the results are dropped like you said and the main execution path shouldn't be affected. It only facilitate information leaks AFAIK.

deleted 9y ago

[deleted]