
W^X enabled in OpenBSD Firefox port - protomyth
http://undeadly.org/cgi?action=article&sid=20151021191401
======
halosghost
I would _love_ to see this make it upstream. I use PaX/grsec under linux and
one of my favorite things about them is that they try to enforce w^x.

Unfortunately, a ton of programs break this policy (seemingly for no benefit).
Having upstream firefox respect w^x anyway would mean I could remove its
exception under PaX and a whole class of possible security flaws just GoAway™.

Ideally, I'd love to see Linux embrace w^x generally, but the kernel devs do
not seem terribly interested in that. Either way, keep up the rockin' work
OpenBSD team!

Edit: Oh wait! The patch for this _is_ actually upstream! This bit of news is
OpenBSD enabling it! That's awesome! /me tries to rebuild firefox with the
patch enabled.

~~~
eugeneionesco
>and a whole class of possible security flaws just GoAway™.

Technically not true, they don't go away, they're just harder(and not that
much harder) to exploit.

~~~
brandmeyer
It changes a broad class of attack exploits to require return-oriented
programming techniques to exploit. Are you seriously claiming that ROP isn't
"that much harder" than injecting arbitrary code?

~~~
jcranmer
libc by itself provides a Turing-complete set of ROP gadgets:
<[http://www.cs.ncsu.edu/faculty/jiang/pubs/RAID11.pdf>](http://www.cs.ncsu.edu/faculty/jiang/pubs/RAID11.pdf>).

~~~
halosghost
First of all: thanks! I'm excited to read this!

Second of all: ugh! Dear HackerNews team, please fix your URL matching
algorithm so it doesn't include <> in URLs; they're actually explicitly
recommended by the URI RFC as delimiters.

Sincerely,

halosghost

------
kbenson
I was going to post something about how I wonder how useful this is since my
understanding is that JIT engines need to be able to write executable code to
memory, and if you can't protect that, which seems to be the largest attack
vector for browsers currently.

Then I actually looked at the post, and it's about enabling W^X on JIT pages
in memory. Very cool.

~~~
simcop2387
I think I remember reading old articles about how they're doing this. Once the
code has been JIT'd they put it on a page (or pages) by itself, and then
toggle the write bit so it can be executed. Once it's JIT'd anyway it won't
ever be changed, other than to maybe be dropped in favor of some other code.
This still can have some security issues if someone can manage to get the JIT
engine to output arbitrary code directly but it prevents a huge class of
attacks of overwriting the JIT pages and getting the browser to then execute
them. Or the usual stack overflows and other things of course.

~~~
the8472
> Once it's JIT'd anyway it won't ever be changed,

That's not necessarily how it works. JITs often use inline caches that get
populated at runtime. JITs usually implement W^X by mapping the same physical
memory into two different address ranges. Once as RW for modification and once
as RX for execution.

Having a single mapping is possible, but comes with performance penalties
because execution needs to reach a safe/bailout point where that can happen
instead of just atomically patching the code.

~~~
simcop2387
Doesn't mapping the same physical memory into two places actually end up
defeating the W^X bit entirely? Since you can write to the RW mapped page and
have it change the RX page?

~~~
the8472
Those pages would be mapped at a different, random address while the executing
code has an instruction pointer pointing right at the RX page.

It's much more difficult getting access to the JIT's internal data structures,
traversing them to find the correct RW page, then modify it, then jump to the
same place in the RX page. If you already have that much control you're
probably not far from getting the JIT to emit arbitrary code anyway.

Note that writing to ICs can happen from a different thread, so the current
thread stack does not need to know much of the JIT's internal data.

------
st3fan
Firefox on iOS, eh?

~~~
TD-Linux
It's buildable and works, but you obviously could never submit it to the App
Store.

~~~
CraftThatBlock
Firefox on iOS [https://appsto.re/ca/-LZ_6.i](https://appsto.re/ca/-LZ_6.i)

~~~
captainmuon
That one uses WebKit. I wonder if anybody actually got Gecko to run on iOS. As
I understand, there are "only" two problems - Apple not allowing other HTML/JS
implementations, and Apple not allowing writable, executable memory. I don't
know what the status of the first is, but you can get around the latter by
just using an interpreter instead of a JIT (which is of course terribly slow).

Or, you decide Apple is never going to let your engine on the App store, and
then you just include the JIT. The enforcement is done at time of submission
to the app store, not at runtime. IIRC, you can just call a certain function
to mark a memory region as writable or executable, but Apple detects this call
statically.

I further wonder if you could just distribute binaries, outside of the app
store, and your users would have $99 developer accounts, and run a little
script to "build their project with XCode", signing and installing it to their
device?

~~~
cpeterso
Prototype builds of Gecko running on iOS do exist, but they are not officially
developed or maintained by Mozilla. You can track the progress of merging iOS
support into the main Firefox repository in this bug:

[https://bugzil.la/1163827](https://bugzil.la/1163827)

~~~
st3fan
That looks pretty official to me.

~~~
cpeterso
Well, you certainly know more about Mozilla's iOS plans than I do :) but I
thought Ted was just working on the patches on his own time, not in any
official capacity.

