OpenBSD Journal

Ted Unangst: Improving Browser Security

Contributed by tbert on from the browsing the crystal ball dept.

In a recent post to misc@, Ted Unangst (tedu@), outlined some of his upcoming work on improving browser security. Ted writes,

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.

It is worth noting that this work is supported by the OpenBSD Foundation, whose annual fundraising drive has just started. Please help more awesome stuff like this happen, head over there with your boss' credit card, right now!

(Comments are closed)


Comments
  1. By Anonymous Coward (92.249.206.112) on

    When will the webbrowsers have a separated user?

    Comments
    1. By Anonymous Coward (62.224.108.132) on

      > When will the webbrowsers have a separated user?

      When you learn how to: http://marc.info/?t=142540166000001&r=1&w=2

  2. By Chas (147.154.235.102) on

    Could we get a ~/.webjail directory where the browser does a setuid to nobody after a chroot? How is it that we are in 2015 and this does not yet exist?

    Comments
    1. By Anonymous Coward (62.224.108.132) on

      > Could we get a ~/.webjail directory where the browser does a setuid to nobody after a chroot? How is it that we are in 2015 and this does not yet exist?

      1) you don't want the "nobody" user; nobody ended up getting more privileges than 'none' over the years
      2) the traditional unix setuid permissions make it impossible for anyone other than root to change the uid of a process; would you trust a browser binary marked as setuid root?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]