WebAssembly Browser Preview

Re:WebAssembly Browser Preview by geofft on Monday October 31, 2016 @04:17PM (#12840539)

Yeah, I think by calling this a "security model" I was simultaneously too generous and too insulting. :) There is definitely a team of smart people at Apple that design the OS / kernel to be secure against apps that are allowed to run arbitrary code; this is where stuff like kernel sandboxing comes from. There is also a team at Apple that tries to prevent apps from running arbitrary code, and does an okay job of it. (I assume this team is also populated by smart people, and they know that they're not actually implementing a foolproof security restriction, they're implementing a policy restriction.) The ban on JITs, as I understand it, comes from the second team. There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right?

[ Parent | on HN ]

Re:WebAssembly Browser Preview by DerekL on Monday October 31, 2016 @05:16PM (#12840983)

> There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right?

An app might have a buffer overflow bug. Allowing all or some of the writable memory to be executable makes it easier for an attacker to exploit such a bug. (An attacker can still exploit the bug without arbitrary native code execution, but it's harder.)

The apps are still protected from one another, so this restriction mainly protects app developers from their own mistakes.

[ Parent | on HN ]

Re:WebAssembly Browser Preview by comex on Monday October 31, 2016 @08:10PM (#12842179)

Yes, I know this is part of the motivation, though I'm not aware how much other factors were involved. Don't want to sound like I know more than I do...

Its usefulness can be debated, since ROP and other techniques are powerful enough for a motivated attacker to go a long way without actually executing code, but it's not fundamentally invalid as an exploit mitigation technique. In fact, PaX implements something similar:

https://pax.grsecurity.net/docs/mprotect.txt

Of course, Apple evidently thinks the speed benefits of JIT are important enough for Safari to be worth letting the browser process not just remap RW to RX but actually map RWX pages - despite the browser process probably being the biggest target of all for exploits. I personally think iOS should allow apps to opt in to doing the same, but that's just my opinion.

[ Parent | on HN ]

Re:WebAssembly Browser Preview by geofft on Monday October 31, 2016 @11:40PM (#12843198)

Wait, you get RWX pages? Is that new-ish? Last I was paying attention to this (around iOS 7 and 8), the kernel support for Safari's JIT gave it a single RW page at a random address, that you could flip to X (not even RW) when done. What's the use of concurrently modifying executable pages?

Maybe I'm confusing this with some other system?

[ Parent | on HN ]

Re:WebAssembly Browser Preview by icebraining on Monday October 31, 2016 @07:31PM (#12841924)

A middle ground is to allow memory to be either writable or executable at any given time, but not both (W^X). At least Firefox's JIT already implements this.

[ Parent | on HN ]

Re:WebAssembly Browser Preview by geofft on Monday October 31, 2016 @10:40PM (#12842947)

Yeah, iOS's JIT does the same thing, I believe (it JITs a page and then turns it execute-only). But it's not completely foolproof since a sufficiently lucky buffer overflow can, in theory, overwrite the JIT page while it is being JITed, and then wait for it to be executed.

[ Parent | on HN ]

Re:WebAssembly Browser Preview by CalChris on Monday October 31, 2016 @07:41PM (#12841985)

W^X, which is a really good+necessary idea, allows ROP. Still I think it's a necessary part of Defense in Depth for JITs which then necessarily leads to some bloat.

[ Parent | on HN ]