Comment by 0x0 | Hacker News Reader

Comment by 0x0 | Hacker News Reader

Parent Full thread

Browsers that bring their own javascript engine will likely also need to support JIT in order to be able to compete with Safari on performace. Doing JIT on iOS requires a special entitlement grant from Apple in order to map memory pages as executable. An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS. Most other regular apps, even if they have a buffer overflow somewhere, will require a lot more fiddling in order to execute arbitrary code, and are thus a lower risk for users to install.

In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard.

To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.

> An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS

No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days.

Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container.

And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function.

So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).

There's been plenty of flaws in the app sandbox, but without the ability to execute arbitrary code they are often much much more difficult to exploit since you won't be able to invoke the particular system call or function you want to hit with just the right arguments.

For now. The EU Product Liability Directive updates and Cyber Resilience Act is going to force software and hardware makers to take a much harder look at their security choices.

But Apple was scanning all applications' executables before Notarization/App Store listing. With browsers or JITs they can't do so.

What I'm hearing from this, is that JITs are a security hazzard so we should all move to interpreted wasm

https://bytecodealliance.github.io/wamr.dev/blog/introductio...

https://v8.dev/docs/wasm-compilation-pipeline

WASM was designed work well with JIT code generation. Interpreted WASM is probably much slower than JIT javascript.

Reply on news.ycombinator.com