Hacker News new | ask | show | jobs
by latiera 4295 days ago
I like how he says 'compiled c++ (to javascript) is immune to buffer overflows' yet completely sidesteps the real issue at hand: Every major javascript virtual machine is riddled with security holes. In Firefox case (no sandbox, no process-per-tab, one of the worst C++ codebases I've ever seen security-wise, _infested_ with memory leaks and UAFs) these holes can effortlessly lead to system compromise. In Chrome case, significantly more work is required.
4 comments

VMs with a direct asm.js compilation mode (like SpiderMonkey) can compile directly to native code (in advance) with the vast majority of the JS attack surface disabled (including heap allocations, for asm.js v1)

In practice it's similar to the way NACL/pNACL can sandbox code due to the limited instruction set & validation guarantees.

> _infested_ with memory leaks and UAFs

Really? That doesn't match my experience -- the full Firefox test suite is run through ASAN on every check-in. (See the "Linux x64 ASAN" results at https://tbpl.mozilla.org/?tree=Mozilla-Inbound, for example).

So I'd be interested to know what you base this claim on.

I wonder how many functions are suppressed from issuing error reports, if any.
There are suppressions for LSAN (http://mxr.mozilla.org/mozilla-central/source/build/sanitize...) and TSAN (http://mxr.mozilla.org/mozilla-central/source/build/sanitize...). But none for ASAN that I could find.

I've talked to the person who implemented the LSAN support, and he says that the LSAN leaks being suppressed are not particularly large.

I also know a person who has recently been running the main test suite through Valgrind. (We do smoketests with Valgrind on every checkin, but not the full suite because it's too slow.) He found a few undefined value errors, which ASAN cannot detect, and which are getting fixed, but no UAFs as far as I know.

Interesting, thanks! Valgrind is indeed very very slow :) I have tried 'undefined behaviour sanitizer' (part of ASAN project I believe), it's not bad.
browser.tabs.remote = true

Now you have separate processes for each tab.

Still, considering that the underlying browsers are implemented in C++, I don't think anyone is under the impression that this is some kind of wonderful security feature.

Bugs exist. Report them. Doesn't change the intent of asm.js to be immune to buffer overflows.