4 ms·

Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless

27 points by vezycash 8y ago

geofft 8y ago
It seems a little unlikely that the browser manufacturers would enable threads in wasm without (being comfortable with) re-enabling SharedArrayBuffers in JS. WebAssembly isn't some outside force, it's basically the same people working on WebAssembly integration and what JS features are permitted in browsers. I think they know that these are the same in terms of security risk.
- malcolmwhite 8y ago
  The wasm folks know and care about the security implications of threading.
  - anon1385 8y ago
    Use of SharedArrayBuffer in timing attacks was widely predicted and there were working examples showing how it could be used to extract information from browsers long before vendors enabled it by default. It's hard to have faith that the people who ignored all those risks won't do so again. It would be an existential crisis for several of the browser vendors if they can't add things like threads with shared memory to javascript/webassembly. The existence of those organisations is based on the idea of the browser being a replacement for native platforms, and if they can't include basic and vital features like threads then they will always be at a huge disadvantage to native platforms. Do you think Mozilla will admit the entire browser-as-platform project is flawed and disband the organisation? Or will they push ahead with these new features despite the risks?
    - geofft 8y ago
      Mozilla is the same organization behind Rust. "Unsteuctured shared-memory concurrency is inherently unsafe, and also not necessary for performance; here's how some structure permits a compiler to make it safe" would be a huge ideological win for certain parts of the company. (Also, meanwhile, none of the native platforms that Mozilla is trying to replace have disabled threads.... so by that standard, Mozilla is already miles more credible here.)
enzanki_ars 8y ago
Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I have yet to see a real reason for browsers to enable WebAssembly with out at least a permission dialog like location services, alerts, flash, etc. The only thing I have heard that uses the feature is the CryptoCurrency miner mentioned in the article and some random demos released by Mozilla. First thing I am doing when I get back to my laptop is finding where the hidden flag to disable WebAssembly is in Firefox and Chrome, as an ad blocker can only go so far with blocking this. I could be very wrong, but I see noting but potential for abuse. If I run across a legitimate use case, I can re-enable the feature on demand. Edit: https://github.com/stevespringett/disable-webassembly/blob/master/README.md https://github.com/stevespringett/disable-webassembly/blob/m... Seems like disabling the feature is a difficult task in all browsers that have WebAssembly except Firefox.
- geofft 8y ago
  How would you phrase the permission dialog? In a paranoid browser targeted at security nerds, I can see it making sense, but how would you explain what WebAssembly is and what the risks are to someone who hasn't heard of it and doesn't have a good sense of what JavaScript is? Also, what do you believe the risks are for you? (Do you find that website convincing? I don't think any of those arguments make sense, so I'm happy to argue against them if you do.) And how do those risks compare to JavaScript itself (including asm.js, or a wasm polyfill)?
  - wybiral 8y ago
    Yeah, I think if you allow JS at all then WebAssembly isn't really adding much risk.
  - enzanki_ars 8y ago
    Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I understand that the page I linked to does not have a solid argument for why it should be disabled. There is a point though the author made that I do agree with, but they did not detail it well. I could be understanding what WebAssembly has and what it could bring, but the way I have read it is that WebAssembly allows users to create desktop like apps with better performance than JS. I am fine with that. The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. Just recently JavaScript had a small bit of that problem with WebUSB. See https://news.ycombinator.com/item?id=16501400 https://news.ycombinator.com/item?id=16501400 and https://news.ycombinator.com/item?id=17332340 https://news.ycombinator.com/item?id=17332340 In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. My understanding is that these binaries are similar to compiled apps that you can run directly on your desktop. Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Am I be over reacting to all of this? Probably. But I would rather be overly cautious that be caught up in a exploit on a service that is not used much. I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven.
Jyaif 8y ago
The browser developers are fully aware of Spectre and Meltdown. This is pure baseless speculation.

27 points by vezycash 8y ago

It seems a little unlikely that the browser manufacturers would enable threads in wasm without (being comfortable with) re-enabling SharedArrayBuffers in JS. WebAssembly isn't some outside force, it's basically the same people working on WebAssembly integration and what JS features are permitted in browsers. I think they know that these are the same in terms of security risk.

malcolmwhite 8y ago
The wasm folks know and care about the security implications of threading.
- anon1385 8y ago
  Use of SharedArrayBuffer in timing attacks was widely predicted and there were working examples showing how it could be used to extract information from browsers long before vendors enabled it by default. It's hard to have faith that the people who ignored all those risks won't do so again. It would be an existential crisis for several of the browser vendors if they can't add things like threads with shared memory to javascript/webassembly. The existence of those organisations is based on the idea of the browser being a replacement for native platforms, and if they can't include basic and vital features like threads then they will always be at a huge disadvantage to native platforms. Do you think Mozilla will admit the entire browser-as-platform project is flawed and disband the organisation? Or will they push ahead with these new features despite the risks?
  - geofft 8y ago
    Mozilla is the same organization behind Rust. "Unsteuctured shared-memory concurrency is inherently unsafe, and also not necessary for performance; here's how some structure permits a compiler to make it safe" would be a huge ideological win for certain parts of the company. (Also, meanwhile, none of the native platforms that Mozilla is trying to replace have disabled threads.... so by that standard, Mozilla is already miles more credible here.)

enzanki_ars 8y ago

Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I have yet to see a real reason for browsers to enable WebAssembly with out at least a permission dialog like location services, alerts, flash, etc. The only thing I have heard that uses the feature is the CryptoCurrency miner mentioned in the article and some random demos released by Mozilla. First thing I am doing when I get back to my laptop is finding where the hidden flag to disable WebAssembly is in Firefox and Chrome, as an ad blocker can only go so far with blocking this. I could be very wrong, but I see noting but potential for abuse. If I run across a legitimate use case, I can re-enable the feature on demand. Edit: https://github.com/stevespringett/disable-webassembly/blob/master/README.md https://github.com/stevespringett/disable-webassembly/blob/m... Seems like disabling the feature is a difficult task in all browsers that have WebAssembly except Firefox.

geofft 8y ago
How would you phrase the permission dialog? In a paranoid browser targeted at security nerds, I can see it making sense, but how would you explain what WebAssembly is and what the risks are to someone who hasn't heard of it and doesn't have a good sense of what JavaScript is? Also, what do you believe the risks are for you? (Do you find that website convincing? I don't think any of those arguments make sense, so I'm happy to argue against them if you do.) And how do those risks compare to JavaScript itself (including asm.js, or a wasm polyfill)?
- wybiral 8y ago
  Yeah, I think if you allow JS at all then WebAssembly isn't really adding much risk.
- enzanki_ars 8y ago
  Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I understand that the page I linked to does not have a solid argument for why it should be disabled. There is a point though the author made that I do agree with, but they did not detail it well. I could be understanding what WebAssembly has and what it could bring, but the way I have read it is that WebAssembly allows users to create desktop like apps with better performance than JS. I am fine with that. The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. Just recently JavaScript had a small bit of that problem with WebUSB. See https://news.ycombinator.com/item?id=16501400 https://news.ycombinator.com/item?id=16501400 and https://news.ycombinator.com/item?id=17332340 https://news.ycombinator.com/item?id=17332340 In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. My understanding is that these binaries are similar to compiled apps that you can run directly on your desktop. Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Am I be over reacting to all of this? Probably. But I would rather be overly cautious that be caught up in a exploit on a service that is not used much. I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven.

Jyaif 8y ago

The browser developers are fully aware of Spectre and Meltdown. This is pure baseless speculation.