Hacker News Reader

Comment by sneak | Hacker News Reader

How long until we realize that JIT was a mistake and that we should offer orders of magnitude slower JS in browsers that is actually safe (or start building webpages without JS at all again, which will probably never happen) lest we give every website the ability to take over our device?

I'd pay real money for a browser with a slow, safe JS interpreter.

View on HN

The v8 engine has a -—jitless option, however it isn’t clear to me whether Chrome allows that as a command line option.

https://v8.dev/blog/jitless

I believe you would do:

  chrome --js-flags="--jitless"

Most of those bugs were in font rendering.

I saw; such a security-focused browser would naturally use only local, trusted fonts and strongly sandbox media playback/decode of any kind, probably in a different process.

We need slow and safe before we can have fast and safe. Either is better than the fast and unsafe we have now.

We should probably unfuck the dangerous morass that is turing-complete font file formats at some point, too.

Firefox at least uses the wasm sandbox for Graphite, the really fancy turing-complete font thing:

https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

Same with Ogg container parsing.

The direction of webdev is webasm delivering full almost-desktop level apps and SPAs vs the documents with some minor scripting of the past.

Slow & safe javascript will simply not be adopted by the market because there is zero incentive to do so. Change the incentives and you will get the change you want.

why do you assume an interpreter is any safer than JIT? kinda like saying arrays are better than matrices.

A JIT will write to memory and then turn the executable bit on.

https://en.wikipedia.org/wiki/W%5EX

you are implying this is the underlying cause for code execution exploit, it is not.

Actually with the font exploits an interpreter would be quite a bit safer. Many of the font exploit chains work by creating line vectors that result in an infinity or NaN throwing a floating point error (with the SeH handler already being overwritten). When running this by JIT... all of this is occurring on the physical CPU. If the floating point calculations were occurring inside an interpreter then the SEH chain can be protected by SEHOP/SAFESEH and the interpreter could implement bounds checks and while retaining the NX bit on everything executing.

a. closing one attack vector does not justify slowing down the entire world. b. you can have the jit compile with any bound checks as you suggested, so still not justifying an interpreter. the only reason for an interpreter is simplicity, once you have a jit there's no logical reason to go back. also when you say NX bit, you do know the interpreter is running code still. it's just doesn't have to be RW (actually jit don't either) which still allows for ROP. there has to be some very specific exploit for these things to have a dramatic effect (ie. can be vs. cannot be exploited) many times there will be several methods to exploit a vuln.

Well, I feel like you are arguing for JIT just for the sake of arguing. The topic we are discussing in this thread is "Interpreted is safer than JIT" which is absolutely true.

Yeah, there are newer ROP mitigations coming down the pipeline, I agree verifiable execution flow remains a major problem.

Timing attacks are easier with a JIT e.g. I have seen eBPF referred to as a spectre-accelerator

Reply on news.ycombinator.com