Theo de Raadt [interview] recently summarized four buffer overflow "solutions" that have been merged into the current OpenBSD tree. These solutions are PROT_* purity, W^X, .rdata, and propolice [story]. When asked how this affects current software, Theo explained, "Zero. It's invisible. We're just tightening up adherence to what POSIX specifies."

'PROT_*' purity "makes a best effort based on the MMU in question to enforce PROT_EXEC as an independent flag." 'W^X', or 'PROT_WRITE XOR PROT_EXEC' seperates the GOT and PLT segments of ELF binaries, preventing a normal unix process from accessing memory that is both writeable and executable. '.rdata' utilizes a read only segment of ELF binaries for the code segment of a program instead of using the read/write segment inherited from a.out binaries. And Propolice is described by Theo as "Stackguard on steriods." Read on for a complete description and explanation of each...

From: Theo de Raadt
To: tech
Subject: recent security changes in openbsd
Date: Thu, 30 Jan 2003 02:11:09 -0700

In the last while, a couple of people in OpenBSD have been putting
some buffer overflow "solutions" into our source tree; under my
continual prodding.  I thought I would summarize some of these and how
they fit together, since what I have seen written up so far has been
wildly inaccurate.  (Bad reporter, no cookie).

These are, in short form:

1) PROT_* purity
2) W^X
3) .rodata
4) propolice

Let me start at the top then.

1)  PROT_* purity

    POSIX systems have three permissions for each page.
	PROT_READ
	PROT_WRITE
	PROT_EXEC
    To control the behaviour of a page, one or's these values together.
    Unfortunately, as you can see from mprotect(2):
     The mprotect() system call changes the specified pages to have protection
     prot. Not all implementations will guarantee protection on a page basis;
     the granularity of protection changes may be as large as an entire re-
     gion.
    This might not be true on a page.  All real Unix systems I know of support
    PROT_READ and PROT_WRITE correctly, but PROT_EXEC has largely been implied
    as soon as you ask for PROT_READ.

    This is because the pmap modules have been poorly written, or because the
    mmu's in question are not fully capable.  This change makes a best effort
    based on the MMU in question to enforce PROT_EXEC as an independent flag.

			BEFORE		AFTER
	   sparc	nope		fully correct
	   sparc64	nope		fully correct
	   alpha	nope		fully correct
	   vax		nope		impossible
	   m68k		nope		impossible
	   hppa		nope		fully correct
	   i386		nope		see Note 1
	   powerpc	nope		see Note 2

    Oh oh.  i386 and powerpc, two very common architecures, have ominous
    notes.  Now you guys know why I want fast sparc64 machines to run.

    Note 1)
	The i386 is not capable of doing per-page execute permission.
	At most it is only capable of drawing a line through the address
	space, by limiting the code segment length (using the code segment
	register).  So we can say, "from 0 to this point is executable"
	and "from that point on to the end of userland is not executable".
	This sucks, but it is the best we can currently do.  We can protect
	the stack, and not much else.

	There are a lot of other i386 details that are interesting to some
	of us, but you don't want to know them.  Anyways we are investigating

	some possible changes that might help us protect more.

	By the way, hammer will not have this problem...

     Note 2)
	The powerpc has a slightly more flexible mechanism than the i386,
	but let me just say it still totally sucks.  We can protect
	the stack, and not much else.

    So what we did here is to make a best effort solution at making the
    stack non-executable on most architectures.  On many others, we have
    also made the data and bss segments non-executable.

    In other words, the VM system needed slight tracks to correct the
    tracking of PROT_EXEC more carefully, and then the pmap modules in
    each architecture was modified to take a `best effort' approach
    towards making PROT_EXEC an independent flag.

2)  W^X.

    W^X is a short form for "PROT_WRITE XOR PROT_EXEC".  The basic
    idea here is that most buffer overflow "eggs" rely on a particular
    feature: That there is memory which they can write to, and then jump
    to.

    What if there was no such memory?  Does a normal Unix process have
    memory that is both writeable and executable?  Turns out they do: In
    particular, (ELF) shared library programs have these two segments
    called GOT and PLT that are (depending on which architecture) normally
    part of the text or data segment.  They are overwritten at times.

    But do they need it?  The change that has been made is to put the
    GOT and PLT into their own segments.  The main goal of course, is to
    try to ensure that at any time, no page in the system is both writeable
    and executable.

    We managed to get it working.  The attackers just lost a place to put
    their buffer overflow egg.  On architectures where goal (1) is fully
    working, that is...

3)  .rodata

    Now there is another problem.  The code segment of a program, called
    the text segment, has two parts in it on most systems: real code,
    and read-only data.  Historically a.out only had text, data and bss
    segments, and it appears that when people moved to ELF they basically
    just didn't use any new features that ELF has.  We've finally now
    moved to a seperate .rodata segment.  Unlike the real text segment
    which is PROT_READ|PROT_EXEC, this new segment is only PROT_READ.

    What difference does this make?  Well, if you manage to find some
    data in a program that looks like instructions you might want to
    run from your exploit, you can no longer do that.  This may sound like
    a minor chance (but there are also cache and performance reasons
    too ;-)

4)  Propolice

    Propolice is, as I like say describe it, "Stackgaurd on steriods".
    Stackgaurd uses a random canary (random value constant per run)
    placed by the function prologue and checked by the function epilogues
    to ensure the return address has not been moved.  It was i386 only
    code.  Propolice is machine independent, running on most of our
    architectures.  As well, Propolice rearranges variables inside a
    stack frame so that the ones most likely to overflow (ie buffers) are
    closest to the canary, thereby making it hard to overwrite pointers or
    regular integers (which it moves down).

We feel that these 4 technologies together will be a a royal pain in
the ass for the typical buffer overflow attacker.

We'll be writing a real paper about all of this later, but perhaps now
people will understand why we are excited about 3.4.



From: Theo de Raadt
Subject: Re: recent security changes in openbsd 
Date: Thu, 30 Jan 2003 02:21:17 -0700

> We'll be writing a real paper about all of this later, but perhaps now
> people will understand why we are excited about 3.4.

and 3.3 too of course ;-)

Almost all of what I described is already in the tree now.  Just
a few mop-up bits to go...



From: Abdul Rehman Gani
Subject: Re: recent security changes in openbsd
Date: Thu, 30 Jan 2003 11:33:10 +0200

On Thursday 30 January 2003 11:11, Theo de Raadt wrote:
>
> We feel that these 4 technologies together will be a a royal pain in
> the ass for the typical buffer overflow attacker.
>
> We'll be writing a real paper about all of this later, but perhaps now
> people will understand why we are excited about 3.4.

Do you have a summary of the affects, if any, these technologies will have as 
far as installing and running s/w is concerned? Especially the install from 
source route that requires the tar/configure/make cycle.

Thanks,

Abdul

-- 
http://www.eastcoast.co.za



From: Theo de Raadt
Subject: Re: recent security changes in openbsd 
Date: Thu, 30 Jan 2003 02:29:46 -0700

> On Thursday 30 January 2003 11:11, Theo de Raadt wrote:
> >
> > We feel that these 4 technologies together will be a a royal pain in
> > the ass for the typical buffer overflow attacker.
> >
> > We'll be writing a real paper about all of this later, but perhaps now
> > people will understand why we are excited about 3.4.
> 
> Do you have a summary of the affects, if any, these technologies will have as 
> far as installing and running s/w is concerned? Especially the install from 
> source route that requires the tar/configure/make cycle.

Zero.  It's invisible.  We're just tightening up adherence to what
POSIX specifies.

Only one thing has cared: emacs, because it does stuff that is
entirely not right, and that has been worked around.

Don't you know us?  You think we'd change it so it isn't Unix?

• Google Archive Of Above Thread