4 ms·

Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?

by nikanj 7y ago

NieDzejkob 7y ago
It's also how wasm works, and in some sense -- JavaScript. Somehow, these introduce much less security problems.
- ixtli 7y ago
  The 'somehow' seems rather clear to me when you look at how the organizations who governed these languages and how they're run.
- iainmerrick 7y ago
  JavaScript doesn’t give you nearly as much access to host OS features as the JVM does. (And there sometimes are security problems when it does.)
  - staticassertion 7y ago
    But it's not really interesting to compare js to java, we should be comparing to ebpf.
- muricula 7y ago
  https://github.com/tunz/js-vuln-db https://github.com/tunz/js-vuln-db I'm not sure Javascript has fewer security problems at all. Sandboxes help a lot, but not all sandboxes are equally strong and Javascript engines routinely get popped.
monocasa 7y ago
Java implemented the sandbox as java code in the same VM as what it was sandboxing, then later attached reflection so you had a billion different ways to get references to those classes blocking your access and do brain surgery on them. Oof. Flash was a lovecraftian horror novel of a code base that even Adobe didn't feel totally comfortable making changes in.
musicale 7y ago
One difference with eBPF is that it limits the number of instructions you can execute (and also prohibits backward branches if I recall - "loops" must be unrolled) and that the semantics are restricted enough that it can be "proven" to be safe. You are correct however that allowing arbitrary eBPF code to be installed by untrusted users increases the attack surface. For example, we need to trust that the eBPF checker is correct, as well as the implementation of the eBPF operations. Moreover, even though eBPF may be safe I suspect it could potentially trigger or exploit bugs in internal kernel subsystems that might be harder or even impossible to trigger through the regular system call interface.

Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?

by nikanj 7y ago

Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?

NieDzejkob 7y ago

It's also how wasm works, and in some sense -- JavaScript. Somehow, these introduce much less security problems.

ixtli 7y ago
The 'somehow' seems rather clear to me when you look at how the organizations who governed these languages and how they're run.
iainmerrick 7y ago
JavaScript doesn’t give you nearly as much access to host OS features as the JVM does. (And there sometimes are security problems when it does.)
- staticassertion 7y ago
  But it's not really interesting to compare js to java, we should be comparing to ebpf.
muricula 7y ago
https://github.com/tunz/js-vuln-db https://github.com/tunz/js-vuln-db I'm not sure Javascript has fewer security problems at all. Sandboxes help a lot, but not all sandboxes are equally strong and Javascript engines routinely get popped.

monocasa 7y ago

Java implemented the sandbox as java code in the same VM as what it was sandboxing, then later attached reflection so you had a billion different ways to get references to those classes blocking your access and do brain surgery on them. Oof. Flash was a lovecraftian horror novel of a code base that even Adobe didn't feel totally comfortable making changes in.

musicale 7y ago

One difference with eBPF is that it limits the number of instructions you can execute (and also prohibits backward branches if I recall - "loops" must be unrolled) and that the semantics are restricted enough that it can be "proven" to be safe. You are correct however that allowing arbitrary eBPF code to be installed by untrusted users increases the attack surface. For example, we need to trust that the eBPF checker is correct, as well as the implementation of the eBPF operations. Moreover, even though eBPF may be safe I suspect it could potentially trigger or exploit bugs in internal kernel subsystems that might be harder or even impossible to trigger through the regular system call interface.