Hacker News Reader

Comment by happybuy | Hacker News Reader

Yes I believe when the SquirrelFish (now Nitro) JS engine was initially announced that it relied on allowing certain items in memory to become executable (most likely due to the JS interpretation and then execution) - and that due to the security model in iOS and the ARM processors this was not allowed.

In general I believe its good to not allow random bits of memory to become executable as it can easily introduce a large number of security and memory overflow vulnerabilities.

Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Which would make sense because they control and are responsible for Safari, but to allow any application to circumvent this restriction could open iOS up to large security issues.

View on HN

>Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application.

Given Safari is the biggest attack surface and regularly falls prey to exploits they should also disable the JIT for Safari. (Most iOS exploits like the Pwn2Own ones, and jailbreakme.com ones are due to bugs in Safari.)

IIRC, the jailbreakme.com exploit relied on a flaw in libtiff.

Entry point was Safari though.

I think this is the answer.

A JIT works by compiling some chunk of code into a section of executable memory, then jumping to that location. As I understand it, iOS hasn't previously allowed execution of code from "data memory" (various people were curious about this very thing when it was announced they were shipping a JIT). Presumably, the Safari process has some special flag that allows it to write to executable memory, but most other processes do not. My guess is that someone forgot to add this flag to whatever application handles "full screen" pages, although maybe there is a legitimate reason for this.

Edit:

An example of the curiosity I mentioned: http://twitter.com/mraleph/status/43030240175468544

Probably time for Apple to start using the process sandboxing from Chromium in Safari. If you are running a jit you need to make data executable so it isnt going away. As Apple control the OS they should be able to design a good Javascript sandbox.

Actually, it looks like Apple's approach is WebKit2 <http://trac.webkit.org/wiki/WebKit2>, which will handle the UI/web process separation itself, allowing any client application to benefit (as opposed to Chromium's current approach).

Perhaps you just meant the UI/web process separation itself, but it's interesting to note that Apple is going for a more general-purpose solution.

When did apple start caring about security?

Reply on news.ycombinator.com