5 ms·

Recently here on Hacker News I had a short discussion with Steve Klabnik about JavaScript and WebAssembly among other things.[0] My point is that to execute ran

by madez 9y ago

Recently here on Hacker News I had a short discussion with Steve Klabnik about JavaScript and WebAssembly among other things.[0] My point is that to execute randomly downloaded code is realistically impossible to secure, practically used to deliver malware and usually used against the interests of the user of the computer. If I can infer from Steve's stance the opinion of Mozilla, then it's sad to see that the only big browser developer organization I had hopes in simply waves these problems away and keeps on making JavaScript and WebAssembly more usable and widespread. It's disheartening to see that. The connection to this talk is that they demo triggering a backdoor hidden in microcode by executing some WebAssembly code in an up-to-date FireFox. [0] https://news.ycombinator.com/item?id=15981178 https://news.ycombinator.com/item?id=15981178

legulere 9y ago
> My point is that to execute randomly downloaded code is realistically impossible to secure This is absolutely not true if you have a MMU and something like a protection ring. In such an environment code by default can do nothing malicious. The only thing making it insecure in any way are the syscalls offered by the operating system.
jcranmer 9y ago
On a von Neumann architecture, there is no actual distinction between code and data. Every CPU architecture in widespread use is a von Neumann architecture (GPUs, it should be noted generally aren't von Neumann). What this means is that loading data from unsecure, untrusted sources is potentially the same as executing code. In practice, this is actually very often the case--a buffer overflow trivially turns data into code. With that in mind, what realistically is possible to do, over than to declare that everything can only be read as plain text (and hope there's no exploitable bugs in font rendering of system fonts)?
- quotemstr 9y ago
  What is "code" anyway except instructions? The Harvard-Von-Neumann distinction is really a continuum. Even today's computers draw important distinctions between data and code: for example, we have separate data and instruction caches, and Linux has special caching behavior for PROT_EXEC pages. (The latter is an annoyance, BTW: there's no reason to treat Java bytecode, say, differently from PROT_EXEC pages. Executable protection should have nothing to do with active or inactive list membership.)
- madez 9y ago
  There is a huge difference from the security perspective between rendering a static HTML site and executing JavaScript. That theoretically they might be close has no practical meaning, and insisting on it may paralyse us into doing nothing. Securing font rendering or HTML rendering is achievable. I suggest replacing the C code by code written in a language with stronger static verification, like Rust. Also, JavaScript and WebAssembly (the latest starting with this talk) are actively used for unauthorized access to computers. It's not like I'm pointing out theoretical attack possibilities. This makes the matter more urgent.
  - jcranmer 9y ago
    What about JS is so odious? That it's Turing complete? Well, so is XSLT, yet you don't seem uptight about people implementing it. JS does provide some very valid use-cases, and two of them that come to mind are interactivity and displaying static data that has no neat representation in HTML (e.g., Mathjax and d3.js for charting). My point is that JS is far from the only massive, complex, potentially security-laden hole in a modern web browser. Audio/video codecs are notoriously complex, and font rendering also has this nasty habit of causing kernel crashes on Windows. These have been used for active exploits. The way you achieve security is you have to look at the risks and work out ways to mitigate them. There are ways to be quite secure even allowing JS execution.
    - pygy_ 9y ago
      The addition of the NX bit to CPUs blurs the line between Von Neuman and Harvard architectures. Giving an attacker a JIT makes it easier for them to lay out memory with the NX bit set to zero (executable memory) that they can later jump into. Return-oriented programming can still be used to hijack a program that whose executable parts are locked down at runtime, having a JIT just makes things easier.
    - y_u_no_rust 9y ago
      > There are ways to be quite secure even allowing JS execution. ;)
- TheAceOfHearts 9y ago
  If I recall correctly, WASM separates code and data, along with a bunch of other security features.
afuchs 9y ago
> [...] My point is that to execute randomly downloaded code is realistically impossible to secure, practically used to deliver malware and usually used against the interests of the user of the computer. [...] This argument has been rehashed over and over again. Some of the mass appeal of the web, as a platform, is that random arbitrary code can be downloaded and run inside a sandbox. It appears that these web technologies will continue to be used regardless of any security implications. If users demand something like JavaScript or WebAssembly, do you have an alternative proposal to satisfy them?
- madez 9y ago
  Rehashing an argument does not make it wrong, and continuing doing so is still important if it's valid and not considered accordingly. Users don't demand JavaScript nor WebAssembly, some developers do. Users want to easily discover new programs/games/whatever. If they were presented those equally easy and convenient in another form, they wouldn't even care. Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. The developers might want to hide parts of their code or underlying data from the user, or force presentation in a certain form (ads), or avoid the orderly way of delivering software through proven ways like distributions, possibly to achieve the former two goals. Now, where does Mozilla stand in this conflict? I realize they don't stand where I thought they would stand. I want the web, but without random drive-by code execution. Code must be delivered by other, more accounted for ways.
  - userbinator 9y ago
    Users don't demand JavaScript nor WebAssembly, some developers do. Exactly. One of the biggest use-cases I see for JS/Wasm is in implementing DRM obfuscation and more insidious advertising/tracking code.
  - kentonv 9y ago
    > Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. This is stating the obvious, but... For anything even mildly interactive, JavaScript is absolutely essential to creating a good (or even bearable) user experience. With purely static HTML, every interaction requires a page reload, which is painful. Users absolutely do want modern, low-latency UX. Moreover, you literally cannot build things like Slack or Google Docs without JavaScript. Users want these products. HTML-only GMail is barely possible but it's really painful to use. Users want GMail with JavaScript. Maybe you don't want these things. Maybe you are happy with pure-HTML interfaces, or doing anything interactive through dedicated native apps. But there are very few people who prefer it that way. Please don't presume to speak for all users, or accuse Mozilla of working against users, when it's your specific needs that are unusual.
drvdevd 9y ago
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.
rft 9y ago
Author here: I chose WebAssembly, because it allowed for easy insertion of an instruction we understand perfectly and can backdoor. With more work we could have highjacked an instruction in the actual binary of Firefox and started the attack from there. WebAssembly simply gives primitives that allow for an easier attack (emitting of a specific instruction, chosing constants and predictive code generation). Not WebAssembly itself enabled the attack, it just made it easier. Exploiting HTML or font rendering is more work, but as you still run known instructions in a known sequence processing known data the primitives are still there. The same can happen for anything that processes foreign data, be it script, video, images or just CSV.
- madez 9y ago
  Let me first thank you for the incredibly important work of finding and documenting behaviour of hardware we use. I see your point. However, if it's harder for the attacker, it is already a win. Also, this is just one example where JavaScript/WebAssembly are used to deliver/activate malware. There are many other examples. Besides that, even if JavaScript/WebAssembly implementations were provably secure (which they aren't), I would be against them for the other reasons I described in other comments here.
marcosdumay 9y ago
Logical sandboxing is a perfectly possible problem that can even be made correct by formal methods. Browsers don't use a proven correct implementation because testing are enough to get almost perfect already. So, are your concerns about side channel attacks? Side channels are nothing more than undocumented (and sometimes unfixable) logical features. Opening the microcode for inspection and making it patchable will only reduce the number of undocumented features.
steveklabnik 9y ago
> If I can infer from Steve's stance the opinion of Mozilla Please take my opinions as my own.
- madez 9y ago
  Sorry for referencing you that way. I can't change it anymore. I could have pointed to decisions taken by Mozilla to explain my disappointment instead of extrapolating from your statements. Even if your view were exactly what I was criticizing Mozilla for (which I neither think, know nor assume), there was no need for that reference since my critique is not specific to a person. It's bad taste to point to a single person. On top of that, the inference wasn't well justified. I realize I handled that badly, and I learn from that. So, I actually thank you for pointing it out politely. I don't mean to justify but rather to give context when I say that these discussion are not easy because there are lots of arguments and comments of varying degree of quality and emotional content, and contradicting voting. It's hard to represent an unpopular opinion. Still no justification whatsoever.
  - steveklabnik 9y ago
    No worries! Just wanted to make it clear :)
madez 9y ago
> If I can infer from Steve's stance the opinion of Mozilla Mozilla's decisions speak for themselves. There is no need to reference individuals, and less so without very solid basis (which there wasn't).

by madez 9y ago

legulere 9y ago

> My point is that to execute randomly downloaded code is realistically impossible to secure This is absolutely not true if you have a MMU and something like a protection ring. In such an environment code by default can do nothing malicious. The only thing making it insecure in any way are the syscalls offered by the operating system.

jcranmer 9y ago

On a von Neumann architecture, there is no actual distinction between code and data. Every CPU architecture in widespread use is a von Neumann architecture (GPUs, it should be noted generally aren't von Neumann). What this means is that loading data from unsecure, untrusted sources is potentially the same as executing code. In practice, this is actually very often the case--a buffer overflow trivially turns data into code. With that in mind, what realistically is possible to do, over than to declare that everything can only be read as plain text (and hope there's no exploitable bugs in font rendering of system fonts)?

quotemstr 9y ago
What is "code" anyway except instructions? The Harvard-Von-Neumann distinction is really a continuum. Even today's computers draw important distinctions between data and code: for example, we have separate data and instruction caches, and Linux has special caching behavior for PROT_EXEC pages. (The latter is an annoyance, BTW: there's no reason to treat Java bytecode, say, differently from PROT_EXEC pages. Executable protection should have nothing to do with active or inactive list membership.)
madez 9y ago
There is a huge difference from the security perspective between rendering a static HTML site and executing JavaScript. That theoretically they might be close has no practical meaning, and insisting on it may paralyse us into doing nothing. Securing font rendering or HTML rendering is achievable. I suggest replacing the C code by code written in a language with stronger static verification, like Rust. Also, JavaScript and WebAssembly (the latest starting with this talk) are actively used for unauthorized access to computers. It's not like I'm pointing out theoretical attack possibilities. This makes the matter more urgent.
- jcranmer 9y ago
  What about JS is so odious? That it's Turing complete? Well, so is XSLT, yet you don't seem uptight about people implementing it. JS does provide some very valid use-cases, and two of them that come to mind are interactivity and displaying static data that has no neat representation in HTML (e.g., Mathjax and d3.js for charting). My point is that JS is far from the only massive, complex, potentially security-laden hole in a modern web browser. Audio/video codecs are notoriously complex, and font rendering also has this nasty habit of causing kernel crashes on Windows. These have been used for active exploits. The way you achieve security is you have to look at the risks and work out ways to mitigate them. There are ways to be quite secure even allowing JS execution.
  - pygy_ 9y ago
    The addition of the NX bit to CPUs blurs the line between Von Neuman and Harvard architectures. Giving an attacker a JIT makes it easier for them to lay out memory with the NX bit set to zero (executable memory) that they can later jump into. Return-oriented programming can still be used to hijack a program that whose executable parts are locked down at runtime, having a JIT just makes things easier.
  - y_u_no_rust 9y ago
    > There are ways to be quite secure even allowing JS execution. ;)
TheAceOfHearts 9y ago
If I recall correctly, WASM separates code and data, along with a bunch of other security features.

afuchs 9y ago

> [...] My point is that to execute randomly downloaded code is realistically impossible to secure, practically used to deliver malware and usually used against the interests of the user of the computer. [...] This argument has been rehashed over and over again. Some of the mass appeal of the web, as a platform, is that random arbitrary code can be downloaded and run inside a sandbox. It appears that these web technologies will continue to be used regardless of any security implications. If users demand something like JavaScript or WebAssembly, do you have an alternative proposal to satisfy them?

madez 9y ago
Rehashing an argument does not make it wrong, and continuing doing so is still important if it's valid and not considered accordingly. Users don't demand JavaScript nor WebAssembly, some developers do. Users want to easily discover new programs/games/whatever. If they were presented those equally easy and convenient in another form, they wouldn't even care. Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. The developers might want to hide parts of their code or underlying data from the user, or force presentation in a certain form (ads), or avoid the orderly way of delivering software through proven ways like distributions, possibly to achieve the former two goals. Now, where does Mozilla stand in this conflict? I realize they don't stand where I thought they would stand. I want the web, but without random drive-by code execution. Code must be delivered by other, more accounted for ways.
- userbinator 9y ago
  Users don't demand JavaScript nor WebAssembly, some developers do. Exactly. One of the biggest use-cases I see for JS/Wasm is in implementing DRM obfuscation and more insidious advertising/tracking code.
- kentonv 9y ago
  > Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. This is stating the obvious, but... For anything even mildly interactive, JavaScript is absolutely essential to creating a good (or even bearable) user experience. With purely static HTML, every interaction requires a page reload, which is painful. Users absolutely do want modern, low-latency UX. Moreover, you literally cannot build things like Slack or Google Docs without JavaScript. Users want these products. HTML-only GMail is barely possible but it's really painful to use. Users want GMail with JavaScript. Maybe you don't want these things. Maybe you are happy with pure-HTML interfaces, or doing anything interactive through dedicated native apps. But there are very few people who prefer it that way. Please don't presume to speak for all users, or accuse Mozilla of working against users, when it's your specific needs that are unusual.

drvdevd 9y ago

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.

rft 9y ago

Author here: I chose WebAssembly, because it allowed for easy insertion of an instruction we understand perfectly and can backdoor. With more work we could have highjacked an instruction in the actual binary of Firefox and started the attack from there. WebAssembly simply gives primitives that allow for an easier attack (emitting of a specific instruction, chosing constants and predictive code generation). Not WebAssembly itself enabled the attack, it just made it easier. Exploiting HTML or font rendering is more work, but as you still run known instructions in a known sequence processing known data the primitives are still there. The same can happen for anything that processes foreign data, be it script, video, images or just CSV.

madez 9y ago
Let me first thank you for the incredibly important work of finding and documenting behaviour of hardware we use. I see your point. However, if it's harder for the attacker, it is already a win. Also, this is just one example where JavaScript/WebAssembly are used to deliver/activate malware. There are many other examples. Besides that, even if JavaScript/WebAssembly implementations were provably secure (which they aren't), I would be against them for the other reasons I described in other comments here.

marcosdumay 9y ago

Logical sandboxing is a perfectly possible problem that can even be made correct by formal methods. Browsers don't use a proven correct implementation because testing are enough to get almost perfect already. So, are your concerns about side channel attacks? Side channels are nothing more than undocumented (and sometimes unfixable) logical features. Opening the microcode for inspection and making it patchable will only reduce the number of undocumented features.

steveklabnik 9y ago

> If I can infer from Steve's stance the opinion of Mozilla Please take my opinions as my own.

madez 9y ago
Sorry for referencing you that way. I can't change it anymore. I could have pointed to decisions taken by Mozilla to explain my disappointment instead of extrapolating from your statements. Even if your view were exactly what I was criticizing Mozilla for (which I neither think, know nor assume), there was no need for that reference since my critique is not specific to a person. It's bad taste to point to a single person. On top of that, the inference wasn't well justified. I realize I handled that badly, and I learn from that. So, I actually thank you for pointing it out politely. I don't mean to justify but rather to give context when I say that these discussion are not easy because there are lots of arguments and comments of varying degree of quality and emotional content, and contradicting voting. It's hard to represent an unpopular opinion. Still no justification whatsoever.
- steveklabnik 9y ago
  No worries! Just wanted to make it clear :)

madez 9y ago

> If I can infer from Steve's stance the opinion of Mozilla Mozilla's decisions speak for themselves. There is no need to reference individuals, and less so without very solid basis (which there wasn't).