A few words about a project I've started working on today with support from
the OpenBSD Foundation.
As you may know, OpenBSD has a W^X (write xor execute) policy for memory.
This mitigates many forms of exploit, either by preventing the exploit from
overwriting the program's executable code or preventing the exploit from
directing control flow to memory it has modified.
Many components of OpenBSD, from the kernel to the toolchain to runtime
components like libc and ld.so, work together to maintain the W^X invariant.
Nevertheless, the policy is only advisory. Writeable executable memory is only
an mmap or mprotect away.
The policy has remained advisory because many JIT engines use such memory and
enforcing mandatory W^X would mean such programs no longer run on OpenBSD. At
the time W^X was introduced, even just the simple change of marking memory
non-executable by default required patches to many programs which assumed all
memory (even including the stack) was exectuable by default.
This is rather unfortunate because it undermines what we're trying to build. A
system that is "all W^X except where it's not" is the same as a system that's
not W^X. We've worked hard to provide a secure foundation for programs; we'd
like to see them take advantage of it.
Which brings me to my new project. The most egregious violator of the W^X
policy on many users' systems will be their browser. We cannot enforce a
stricter W^X policy until at least one browser is fixed. To that end, the
Foundation has hired me to make the necessary changes. The project has only
started today, so there's not much more to announce other than its start, but
I wanted to let people know what's up. More updates to follow as things
The intitial focus is on browser JIT engines, because that's on the critical
path to any policy change, although the end result should be improved security
One may reasonably ask, since the advent of ROP exploits, whether non-exec
memory is still an effective exploit mitigation? I say surely yes. ROP was
developed in part because non-exec memory made simpler exploit
techniques obsolete. The development of more advanced exploits does not mean
we need to tolerate simpler exploits as well. Instead, we should always work
to make things as difficult to exploit as possible, even if we can't reach
I'd like to thank the OpenBSD Foundation for supporting this effort, and the
many donors who have supported the Foundation. The Foundation wouldn't be in a
position to support projects like this if it weren't for you.
On Sun, March 1, 2015 1:36 pm, Ted Unangst wrote:
> I'd like to thank the OpenBSD Foundation for supporting this effort, and
> many donors who have supported the Foundation. The Foundation wouldn't be
> in a
> position to support projects like this if it weren't for you.
My thanks, as well. I've always hoped for OBSD to help tackle the browser
situation. On my way to the donation page in support of this effort.
On 03/01/2015 10:36 AM, Ted Unangst wrote:
> A few words about a project I've started working on today with support from
> the OpenBSD Foundation.
This is a good idea. I just threw some more coin in the donations bin.
At the risk of feature creep:
There was a thread on this list about browser installation
such that it would, for each user be sandboxed in a clean room, denying any
scripts access to the users files. I don't know if this is at all appropriate for
this project, and I just throw it out there for consideration.
> At the risk of feature creep:
> There was a thread on this list about browser installation
> such that it would, for each user be sandboxed in a clean room, denying any
> scripts access to the users files. I don't know if this is at all
> appropriate for
> this project, and I just throw it out there for consideration.
> http://marc.info/?l=openbsd-misc&m=141710381310891&w=2 >
I think Ted is going to fix the so called "we do 64 bit random" and "we are
64 bit" lies that browser JITs say they do. I remember when Ariane applied
the commits, browsers failed spectacularly. Please correct me if i am wrong.