3 ms·

Exploiting browser bugs is still just exploiting browser bugs and this is already a problem for JavaScript, WASM doesn't make it worse. Flash introduces a secon

Exploiting browser bugs is still just exploiting browser bugs and this is already a problem for JavaScript, WASM doesn't make it worse. Flash introduces a second, black box sandbox implemented by morons.

bilbo0s 8y ago
I don't think you're understanding. Let me be explicit. There are changes in WASM specifically made that render spectre and meldown mitigations useless. (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Developers cheer the changes, because they make WASM more useful, and to be fair, browser mitigations of spectre and meltdown type bugs make WASM far less performant. But changes which render those mitigations useless are dangerous no matter what your opinion is on how useful WASM should be. Edit: Should probably mention that the upcoming changes include threading and shared memory. Implemented in a way that enables CPU side channel attacks. (Probably because there is no other way to get threading and shared memory without everything slowing to a crawl, but still.)
- Sir_Cmpwn 8y ago
  Maybe I don't understand Spectre and Meltdown, then. I wasn't aware it was the browser's business to patch that, I thought it was kernel and microcode patches?
  - bilbo0s 8y ago
    Kernel and microcode patches allow the OS to control for meltdown a bit better. The problem with Spectre is that it is a bit different. Array bounds class might be able to be patched in the long run, but even from the beginning, people have suspected that the other classes of spectre would be more slippery. And true to form, new spectre type variants continue to be discovered and disclosed by Intel even to this day. (SpectreRSB for instance.) In short, it's not a simple patch that will fix all these strains of bugs out there. In light of that fact, browser makers have implemented mitigations at the application level which are a bit more heavy handed. But, as you can imagine, this is going to impact all content inside the browser. Which brings us to the WASM content, and the threading and shared memory changes. And you know the rest of the story from there.
- titzer 8y ago
  > (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Could you be more specific? I implemented Chrome's Spectre mitigations for WASM and I'm not sure what you are referring to. > Should probably mention that the upcoming changes include threading and shared memory. These only give you a high-resolution timer mechanism--which you have to build yourself and is possible in JS with SharedArrayBuffer before. So WASM is no worse in this respect.
- UncleEntity 8y ago
  It's probably a good thing that a standard isn't designed around Vulnerability of the Day, no? Some time in the (near?) future those vulnerabilities will just be a footnote in some history book and having to support mitigations forever (due to backwards compatibility) probably isn't the best thing to encode into a standard. I'm sure some intrepid security researcher will find some new Vulnerability of the Day which can also be exploited through wasm and then they will need to add mitigation to the standard yet again ad nauseam until it becomes some giant bloated unusable mess for which we'll need yet another standard.

bilbo0s 8y ago

I don't think you're understanding. Let me be explicit. There are changes in WASM specifically made that render spectre and meldown mitigations useless. (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Developers cheer the changes, because they make WASM more useful, and to be fair, browser mitigations of spectre and meltdown type bugs make WASM far less performant. But changes which render those mitigations useless are dangerous no matter what your opinion is on how useful WASM should be. Edit: Should probably mention that the upcoming changes include threading and shared memory. Implemented in a way that enables CPU side channel attacks. (Probably because there is no other way to get threading and shared memory without everything slowing to a crawl, but still.)

Sir_Cmpwn 8y ago
Maybe I don't understand Spectre and Meltdown, then. I wasn't aware it was the browser's business to patch that, I thought it was kernel and microcode patches?
- bilbo0s 8y ago
  Kernel and microcode patches allow the OS to control for meltdown a bit better. The problem with Spectre is that it is a bit different. Array bounds class might be able to be patched in the long run, but even from the beginning, people have suspected that the other classes of spectre would be more slippery. And true to form, new spectre type variants continue to be discovered and disclosed by Intel even to this day. (SpectreRSB for instance.) In short, it's not a simple patch that will fix all these strains of bugs out there. In light of that fact, browser makers have implemented mitigations at the application level which are a bit more heavy handed. But, as you can imagine, this is going to impact all content inside the browser. Which brings us to the WASM content, and the threading and shared memory changes. And you know the rest of the story from there.
titzer 8y ago
> (ie-Browser makers put in spectre and meltdown mitigations, and changes in WASM allow WASM content to get around those mitigations.) Could you be more specific? I implemented Chrome's Spectre mitigations for WASM and I'm not sure what you are referring to. > Should probably mention that the upcoming changes include threading and shared memory. These only give you a high-resolution timer mechanism--which you have to build yourself and is possible in JS with SharedArrayBuffer before. So WASM is no worse in this respect.
UncleEntity 8y ago
It's probably a good thing that a standard isn't designed around Vulnerability of the Day, no? Some time in the (near?) future those vulnerabilities will just be a footnote in some history book and having to support mitigations forever (due to backwards compatibility) probably isn't the best thing to encode into a standard. I'm sure some intrepid security researcher will find some new Vulnerability of the Day which can also be exploited through wasm and then they will need to add mitigation to the standard yet again ad nauseam until it becomes some giant bloated unusable mess for which we'll need yet another standard.