5 ms·

His reasoning seems shaky to me. Assuming this new JS engine is a security risk (it's not really, but lets pretend) you're not protecting anyone by making it S

His reasoning seems shaky to me. Assuming this new JS engine is a security risk (it's not really, but lets pretend) you're not protecting anyone by making it Safari-only. It'd be like leaving all your ground-floor windows wide open, whilst locking your front and back doors in hopes that it will discourage burglars. If the new JS engine is a security problem either fix it or remove it. Compromise helps no one.

bigiain 16y ago
I'm not sure which I'd rather see - Gruber being proved wrong (again), or a whole class of new remote "visit this site to jailbreak your iPhone" exploits...
rayiner 16y ago
It's not the JS engine that's the security problem. It's that the JS engine requires allowing apps to mark pages as executable. Executable pages opens up a whole another vector of attacks that have nothing to do with dangerous JS apps.
- kenjackson 16y ago
  That doesn't make any sense. It requires allowing the JIT to mark pages as executable. But that's exactly the same as the browser. There should not be any new security vector exposed that's not already there from the browser.
  - rahoulb 16y ago
    But aren't they within the same process? (I'm asking an honest question - I know nothing of iOS internals). Doesn't that imply that the JIT has privileged access to pages that other code within the same process does not? As saurik (who knows about these things) mentions elsewhere, Apple can trust Safari to not tamper with the executable pages - can they trust 3rd party apps? Home-screen based web-apps being another question entirely.
    - kenjackson 16y ago
      They might be in the same process. I guess they don't do process isolation for hosted browser controls? If not, they should. Otherwise the app stack is always at risk of running arbitrary javascript in process.
  - Someone 16y ago
    The new vector is that, in Safari's case, Apple audited the code that calls the JIT. If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen. Of course, that app would need to pass the app store approval process to be useful, but that should not be hard. A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
    - kenjackson 16y ago
      A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
      - Someone 16y ago
        Chrome and IE run on systems with faster processors and Gigabytes of RAM. RAM, especially is tight on iOS devices. I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.
saurik 16y ago
Apple can't turn on the ability to do executable, dynamically written to memory pages just for their library: they'd have to turn it on for the entire process, at which point you could also do crazy things like download native code and execute it, bypassing the entire concept of their "codesign" mechanism.
- danilocampos 16y ago
  Parent's credentials include Cydia, so this is probably the most valuable comment we're going to see in this whole thread. Thanks for weighing in, sir – this was just the expert opinion I was hoping to see.
- joezydeco 16y ago
  Not just bypassing code signing, but the App Store approval process altogether?
  - saurik 16y ago
    The application that is downloading and executing code would itself have to be signed, so this doesn't get around the App Store approval process: the bootstrap app could be loaded by anyone with a developer certificate, but then they can just sign anything they want that runs as a normal process. The effects this would have are in: a) security (although codesign is a fundamentally flawed system due to return-oriented programming techniques and is frankly just security theatre at this point) b) meta-store fronts (Apple would have to be much more careful about approving applications that downloaded other applications at runtime; Apple could revoke these, though, and you can already do stuff like this with interpreters, although you might not want to bother) and, I'd say most importantly, c) JITs (suddenly there would be no technical obstacles to having good versions of Java, Mono, or even Flash; and given that the contractual obligations they added got so much pushback that they were removed, we /would/ see good versions of Java, Mono, and even Flash)
- ootachi 16y ago
  Are home screen-pinned web apps separate processes? This makes sense for UIWebViews, but not for web apps pinned to the home screen.
schrototo 16y ago
It's not the JavaScript engine that's the security risk, it's that in order to run the new JS engine, the app running it has to be able to execute code from writable memory. This is where the security risk lies, and it has always been forbidden, for all apps. Safari can get an exception, since Apple obviously trusts its own code not to be malicious. But 3rd party apps still won't be allowed to execute arbitrary code from memory, so any apps embedding a UIWebView to present a browser can't get the performance improvements of the new engine. The only real question is why Apple's own app that's used to display those saved-to-home-screen webapps didn't get an exception alongside Safari. My guess is that the Nitro engine is built directly into Safari and that the UIWebView control (which is used by webapp viewer app) simply can't use it at all, regardless of ability to execute writable code. I'm sure this will change, either the viewer app will get rewritten, or UIWebView will get its own sandbox etc. They probably just didn't have the time to do that yet.

bigiain 16y ago

I'm not sure which I'd rather see - Gruber being proved wrong (again), or a whole class of new remote "visit this site to jailbreak your iPhone" exploits...

rayiner 16y ago

It's not the JS engine that's the security problem. It's that the JS engine requires allowing apps to mark pages as executable. Executable pages opens up a whole another vector of attacks that have nothing to do with dangerous JS apps.

kenjackson 16y ago
That doesn't make any sense. It requires allowing the JIT to mark pages as executable. But that's exactly the same as the browser. There should not be any new security vector exposed that's not already there from the browser.
- rahoulb 16y ago
  But aren't they within the same process? (I'm asking an honest question - I know nothing of iOS internals). Doesn't that imply that the JIT has privileged access to pages that other code within the same process does not? As saurik (who knows about these things) mentions elsewhere, Apple can trust Safari to not tamper with the executable pages - can they trust 3rd party apps? Home-screen based web-apps being another question entirely.
  - kenjackson 16y ago
    They might be in the same process. I guess they don't do process isolation for hosted browser controls? If not, they should. Otherwise the app stack is always at risk of running arbitrary javascript in process.
- Someone 16y ago
  The new vector is that, in Safari's case, Apple audited the code that calls the JIT. If UIWebView could JIT, somebody would write an app that dumps the JITs code (I assume that ARM does not have the ability to mark pages as 'executable, but not readable') and run it on a development system. From there, (s)he would figure out what the JIT does to make data executable. That knowledge could be used in an app that can execute code that Apple hasn't seen. Of course, that app would need to pass the app store approval process to be useful, but that should not be hard. A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things. Alternatively, Apple could not have spent the time to do so (yet).
  - kenjackson 16y ago
    A way around this is to move the JIT to the kernel or to a different process. I would guess that that would hinder performance so much that, in typical usage, JIT-ting becomes too expensive to speed up things Having the hosted browser in a different process shouldn't be too expensive. That's what Chrome and IE do. When you open up a UIWebView and process gets spun up that hosts the JIT (amongst the other plubming for the browser) and the host just has a window where the rendering takes place. This also fixes a whole host of other security problems hosting a browser in process.
    - Someone 16y ago
      Chrome and IE run on systems with faster processors and Gigabytes of RAM. RAM, especially is tight on iOS devices. I also guess that some iOS apps will want to overlay stuff on their web views, postprocess the data, register callbacks, etc. Supporting such use might be a bit of work that Apple hasn't done yet.

saurik 16y ago

Apple can't turn on the ability to do executable, dynamically written to memory pages just for their library: they'd have to turn it on for the entire process, at which point you could also do crazy things like download native code and execute it, bypassing the entire concept of their "codesign" mechanism.

danilocampos 16y ago
Parent's credentials include Cydia, so this is probably the most valuable comment we're going to see in this whole thread. Thanks for weighing in, sir – this was just the expert opinion I was hoping to see.
joezydeco 16y ago
Not just bypassing code signing, but the App Store approval process altogether?
- saurik 16y ago
  The application that is downloading and executing code would itself have to be signed, so this doesn't get around the App Store approval process: the bootstrap app could be loaded by anyone with a developer certificate, but then they can just sign anything they want that runs as a normal process. The effects this would have are in: a) security (although codesign is a fundamentally flawed system due to return-oriented programming techniques and is frankly just security theatre at this point) b) meta-store fronts (Apple would have to be much more careful about approving applications that downloaded other applications at runtime; Apple could revoke these, though, and you can already do stuff like this with interpreters, although you might not want to bother) and, I'd say most importantly, c) JITs (suddenly there would be no technical obstacles to having good versions of Java, Mono, or even Flash; and given that the contractual obligations they added got so much pushback that they were removed, we /would/ see good versions of Java, Mono, and even Flash)
ootachi 16y ago
Are home screen-pinned web apps separate processes? This makes sense for UIWebViews, but not for web apps pinned to the home screen.

schrototo 16y ago

It's not the JavaScript engine that's the security risk, it's that in order to run the new JS engine, the app running it has to be able to execute code from writable memory. This is where the security risk lies, and it has always been forbidden, for all apps. Safari can get an exception, since Apple obviously trusts its own code not to be malicious. But 3rd party apps still won't be allowed to execute arbitrary code from memory, so any apps embedding a UIWebView to present a browser can't get the performance improvements of the new engine. The only real question is why Apple's own app that's used to display those saved-to-home-screen webapps didn't get an exception alongside Safari. My guess is that the Nitro engine is built directly into Safari and that the UIWebView control (which is used by webapp viewer app) simply can't use it at all, regardless of ability to execute writable code. I'm sure this will change, either the viewer app will get rewritten, or UIWebView will get its own sandbox etc. They probably just didn't have the time to do that yet.