[prev in list] [next in list] [ prev in thread ] [next in thread] List: openbsd-misc Subject: improving browser security From: "Ted Unangst" <tedu () tedunangst ! com> Date: 2015-03-01 18:36:07 Message-ID: 1e61ba15.da77d112.22e49d45 () tedunangst ! com [Download RAW message or body] 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 actually happen. 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 for everyone. 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 impossible. 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. [prev in list] [next in list] [ prev in thread ] [next in thread]