4 ms·

Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems

by ptx 5y ago

Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems that Java suffered from?

monocasa 5y ago
Java's perennial security issues was that the sandboxing mechanism was implemented in Java in the same VM as it was trying to sandbox... then they added reflection. They couldn't plug all of the holes that could let you get a reference to the security management objects and go to town on them with reflection.
PoignardAzur 5y ago
> Once the GC proposal lands "Once". That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.
pjmlp 5y ago
WASM security story is sales talk, as anyone that understands pentesting is aware of.
- anderspitman 5y ago
  I'd be interested in hearing more about this if you can point to some resources.
  - pjmlp 5y ago
    You can start here, "USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances. A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module. Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases. And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.
    - anderspitman 5y ago
      Thanks!

by ptx 5y ago

Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems that Java suffered from?

monocasa 5y ago

Java's perennial security issues was that the sandboxing mechanism was implemented in Java in the same VM as it was trying to sandbox... then they added reflection. They couldn't plug all of the holes that could let you get a reference to the security management objects and go to town on them with reflection.

PoignardAzur 5y ago

> Once the GC proposal lands "Once". That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.

pjmlp 5y ago

WASM security story is sales talk, as anyone that understands pentesting is aware of.

anderspitman 5y ago
I'd be interested in hearing more about this if you can point to some resources.
- pjmlp 5y ago
  You can start here, "USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances. A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module. Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases. And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.
  - anderspitman 5y ago
    Thanks!