5 ms·

Sorry if this is a dead point that’s already been discussed but: if the code is sandboxed then what is the difference between arbitrary WebAssembly and arbitrar

Sorry if this is a dead point that’s already been discussed but: if the code is sandboxed then what is the difference between arbitrary WebAssembly and arbitrary JavaScript other than speed? It all comes down to instructions executing in the same sandbox doesn’t it? From a security perspective what does this actually change? Is it just that there’s a greater capacity for obfuscation?

madez 9y ago
It makes the use-case for this type of code deployment wider, it's more effective at what it's already used for, and it's also less auditable. These are three reasons why developing and supporting WebAssembly is finally against the interest of the users. The harder, less efficient and cumbersome this type of drive-by code deployment is, the less attractive and used it'll be. Also, sandboxing helps only until it doesn't. It's a futile task, especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality.
- kentonv 9y ago
  Hi. I write sandboxes for a living. > Also, sandboxing helps only until it doesn't. It's a futile task, It really isn't futile. How many major security holes in Chrome's sandbox have actually done serious damage? Yes, they happen from time to time, but not that often, and they are automatically patched shortly after (or before) disclosure, making them really uninteresting for attackers to try to exploit. Realistically, the biggest security threat to real users is phishing or similar deception. Many users can be fooled by a page that looks like an error from their operating system telling them that their computer has a virus and they should download a tool to fix it. You don't need JavaScript for that. Realistically, the highest-impact non-user-error security problems are logic flaws in complicated server code that never intended to run attacker-supplied code in the first place. Think SQL injection, confused deputies, missing access control checks, buffer overruns, SMB (Windows file sharing) bugs exploited by worms, etc. Ironically, modern JavaScript sandboxing is so good -- with so much careful scrutiny by really smart security researchers -- that realistically it's not remotely the easiest target on your system these days. The easy targets are the software that isn't written with security in mind, and the users themselves (phishing). > especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality. JavaScript and WebAssembly don't have direct access to hardware. WebAssembly is not assembly, it's a platform-neutral bytecode that gets recompiled for the host after download.
- drvdevd 9y ago
  Although I take your points, I disagree that JavaScript is more auditable as-is. In either case I will need tools to unwind/flatten/de-obfuscate the code and audit it. I believe it would take me about the same amount of time in either case, depending on the scope of the audit. Regardless, it’s a trade off. Although I agree we should have a web that doesn’t need JavaScript to function - I believe that is a separate argument - I think in this case, while we already have it, I’ll take WebAssembly for the speed and new applications it helps support. I certainly wouldn’t want to see “Web Assembly” blobs in my browser that I’m not allowed to inspect, which again is another argument, IMO.
taxreform 9y ago
From my experiences of reversing Windows x86 applications, I don't think WebAssembly has a greater capacity for obfuscation. In fact, I think WebAssembly is less capable of obfuscating code than JavaScript. It is because WASM does not allow self-modifying code, which is a highly effective obfuscation technique as it can hinder static analysis. On the other hand, JavaScript has eval among other things that can be used to dynamically craft and execute code during execution. I've never seen such JavaScript but it would be quite cumbersome to trace code within a call to eval within a call to eval, and so on. You might need to build a custom V8 to record strings passed to eval when reversing such code.

madez 9y ago

It makes the use-case for this type of code deployment wider, it's more effective at what it's already used for, and it's also less auditable. These are three reasons why developing and supporting WebAssembly is finally against the interest of the users. The harder, less efficient and cumbersome this type of drive-by code deployment is, the less attractive and used it'll be. Also, sandboxing helps only until it doesn't. It's a futile task, especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality.

kentonv 9y ago
Hi. I write sandboxes for a living. > Also, sandboxing helps only until it doesn't. It's a futile task, It really isn't futile. How many major security holes in Chrome's sandbox have actually done serious damage? Yes, they happen from time to time, but not that often, and they are automatically patched shortly after (or before) disclosure, making them really uninteresting for attackers to try to exploit. Realistically, the biggest security threat to real users is phishing or similar deception. Many users can be fooled by a page that looks like an error from their operating system telling them that their computer has a virus and they should download a tool to fix it. You don't need JavaScript for that. Realistically, the highest-impact non-user-error security problems are logic flaws in complicated server code that never intended to run attacker-supplied code in the first place. Think SQL injection, confused deputies, missing access control checks, buffer overruns, SMB (Windows file sharing) bugs exploited by worms, etc. Ironically, modern JavaScript sandboxing is so good -- with so much careful scrutiny by really smart security researchers -- that realistically it's not remotely the easiest target on your system these days. The easy targets are the software that isn't written with security in mind, and the users themselves (phishing). > especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality. JavaScript and WebAssembly don't have direct access to hardware. WebAssembly is not assembly, it's a platform-neutral bytecode that gets recompiled for the host after download.
drvdevd 9y ago
Although I take your points, I disagree that JavaScript is more auditable as-is. In either case I will need tools to unwind/flatten/de-obfuscate the code and audit it. I believe it would take me about the same amount of time in either case, depending on the scope of the audit. Regardless, it’s a trade off. Although I agree we should have a web that doesn’t need JavaScript to function - I believe that is a separate argument - I think in this case, while we already have it, I’ll take WebAssembly for the speed and new applications it helps support. I certainly wouldn’t want to see “Web Assembly” blobs in my browser that I’m not allowed to inspect, which again is another argument, IMO.

taxreform 9y ago

From my experiences of reversing Windows x86 applications, I don't think WebAssembly has a greater capacity for obfuscation. In fact, I think WebAssembly is less capable of obfuscating code than JavaScript. It is because WASM does not allow self-modifying code, which is a highly effective obfuscation technique as it can hinder static analysis. On the other hand, JavaScript has eval among other things that can be used to dynamically craft and execute code during execution. I've never seen such JavaScript but it would be quite cumbersome to trace code within a call to eval within a call to eval, and so on. You might need to build a custom V8 to record strings passed to eval when reversing such code.