OpenBSD Journal

More Security: WxorX

Contributed by jose on from the ELF-pages dept.

Dale Rahn recently checked in WorX for ELF architectures . WxorX is "Write or eXecute", meaning that pages can be writable or executable but not both. This allows ELF architectures to add to their stack and heap protection by thwarting the utility of common attacks which overwrite memory pages of an executable. The (lengthy) commit message is below.

From the original check-in:

This is a project to modify executables so that they do not have any
 executable regions which are writable. If a section of an executable is
 writable and executable, it is much easier for errant code to modify the
 executable's behavior.

 Two current areas in shared library environments which have this
 critical problem are the GOT (Global Offset Table) and PLT (Procedure
 Linkage Table). The PLT is required to be executable and both GOT and
 PLT are writable on most architectures. On most ELF architecture
 machines this would cause shared libraries to have data and BSS marked
 as executable.

 Padding to the linker script for programs and shared libraries/objects
 to isolate the GOT and PLT into their own load sections in the
 executables. This allows only the text(readonly) region and the PLT
 region to be marked executable with the normal data and BSS not marked
 as executable. The PLT region is still marked executable on most
 architectures because the PLT lives in the "data" or "BSS" regions
 and the dynamic loader will need to modify it. Since the GOT and PLT
 should only ever be written by the dynamic linker, it will be modified
 to mprotect those regions so that they are not writable during normal
 execution. If the dynamic linker needs to modify the regions later,
 (eg for lazy binding), it will mprotect the region, make the necessary
 changes, and mprotect it back. Since it is possible to receive a
 signal which would interrupt the program flow and perhaps cause the
 dynamic linker to modify the same (or nearby) PLT references, it is now
 necessary for signals to be blocked for the duration of the mprotect.
As said before, this is only for ELF architectures (presently PPC, SPARC, SPARC64, Alpha are the released ELF architectures). Way to go, Dale!

(Comments are closed)

  1. By Anonymous Coward () on

    Anybody have rough statistics on how many OpenBSD installations run on i386 architecture? More than 95%?

  2. By Anonymous Coward () on

    You know, the ones to prevent the stack from getting smshed. Does this make them sort of redundant/gratuitous?

  3. By Anonymous Coward () on

    In one of my classes, we were talking about the Harvard and Von Neumann architectures. Someone suggested that a limitation of the Harvard architecture was that you couldn't have self-modifying code because the code existed in read-only memory (I suggested that that approach was a huge plus in a lot of causes). It looks like this is the same idea. How much code is self-modifying? I'd imagine that most of it isn't, but what about the few special applications that are?

  4. By James Moss () moss at acmeunix dot org on mailto:moss at acmeunix dot org

    I look forward to the day when i386 goes ELF. Don't get me wrong, I love PPC, SPARC, HPPA, but I have i386 boxes as well, so I'd like to see that go to ELF as well. I've seen mention of it, and I think sometime in the not too distant past I read "after 3.3 release". Anyone else have more confirmation? A brief search via google shows a few other inquirees about it, but no dates/times or aims/goals... other than 'sometime soon'.

  5. By Anonymous Coward () on

    So the first mail-action didn't work...
    Well, time for another one :)
    Maybe someone should assemble a list of e-mail addresses of Sun people who can be contacted about this, and maybe a template e-mail or something.
    Maybe they'll just give Theo the docs to make us stop then ;)


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 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.]