3 ms·

There is a huge difference from the security perspective between rendering a static HTML site and executing JavaScript. That theoretically they might be close h

by 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. ;)

by madez 9y ago

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. ;)