4 ms·

I'd assume they're working at the OS level since part of the exploit involves the hardware (hyperthreading)...

saagarjha 7y ago
> To protect against attacks on affected CPUs make sure your microcode is up to date and disable hyper-threading (HT). I wonder what they can honestly even do beyond disabling hyper-threading by default…
- tinus_hn 7y ago
  They could coordinate with Chrome and allow it to request the kernel that it doesn’t put secure and insecure processes of it on the same processor at the same time, or just disable hyperthreading for Chrome.
- baybal2 7y ago
  > However, the browser process is also using URLLoaderFactories for different purposes and those have additional privileges. Besides ignoring the same-origin policy, they are also allowed to upload local files. Thus, if we can leak one of their port names we can use it to upload /etc/passwd to My take on it. Chrome has just too many things it uses internally that's exploitable if one finds a a way to trick the sandbox. The entire point of sandbox seem to be lost when so many stuff happens inside it. Kick unneeded stuff out from rendering processes, reverting to the original design for them. "The renderer" in their design does way to many things other than just rendering. Again, WASM will be a bane no matter how you secure it. JIT compilation of unsecure code is a bane. ASMJS has been a source of multiple exploits, it's poorly maintained, it must be axed.
  - saagarjha 7y ago
    > Kick unneeded stuff out from rendering processes, reverting to the original design for them. I'm assuming that this would be slow.
  - pjmlp 7y ago
    WebAssembly advocates keep hand waving the fact that internal memory state inside modules is open to data corruption, because bounds checking only happen at the edges of linear memory segments. Something like Heartbleed is not preventable on current WebAssembly sandbox model. So I just keep expecting for the first wave of Flash like exploits to eventually come in, when WebAssembly starts being a valuable target.

> To protect against attacks on affected CPUs make sure your microcode is up to date and disable hyper-threading (HT). I wonder what they can honestly even do beyond disabling hyper-threading by default…

tinus_hn 7y ago
They could coordinate with Chrome and allow it to request the kernel that it doesn’t put secure and insecure processes of it on the same processor at the same time, or just disable hyperthreading for Chrome.
baybal2 7y ago
> However, the browser process is also using URLLoaderFactories for different purposes and those have additional privileges. Besides ignoring the same-origin policy, they are also allowed to upload local files. Thus, if we can leak one of their port names we can use it to upload /etc/passwd to My take on it. Chrome has just too many things it uses internally that's exploitable if one finds a a way to trick the sandbox. The entire point of sandbox seem to be lost when so many stuff happens inside it. Kick unneeded stuff out from rendering processes, reverting to the original design for them. "The renderer" in their design does way to many things other than just rendering. Again, WASM will be a bane no matter how you secure it. JIT compilation of unsecure code is a bane. ASMJS has been a source of multiple exploits, it's poorly maintained, it must be axed.
- saagarjha 7y ago
  > Kick unneeded stuff out from rendering processes, reverting to the original design for them. I'm assuming that this would be slow.
- pjmlp 7y ago
  WebAssembly advocates keep hand waving the fact that internal memory state inside modules is open to data corruption, because bounds checking only happen at the edges of linear memory segments. Something like Heartbleed is not preventable on current WebAssembly sandbox model. So I just keep expecting for the first wave of Flash like exploits to eventually come in, when WebAssembly starts being a valuable target.