Message-ID: <20070514223337.GA31549@grsecurity.net>
Date: Mon, 14 May 2007 18:33:37 -0400
From: spender@...ecurity.net (Brad Spengler)
To: Steve Grubb <sgrubb@...hat.com>
Cc: full-disclosure@...ts.grok.org.uk, dailydave@...ts.immunitysec.com
Subject: Re: [Dailydave] What RedHat doesn't want you to
	know about ExecShield (without NX)

> SE Linux has nothing to do with buffer overflows besides checking that the 
> memory permissions are sane. The buffer overflow detection is a combination 
> of gcc and glibc.

That's funny, because the article tells me:
"Second, even in the unconfined user space, SELinux protects against 
buffer overflow attacks by performing executable memory checks. Buffer 
overflow attacks are a classic system exploit technique. An overflow 
writes more memory than a buffer is configured to hold, and includes 
executable code in the data being written. In Red Hat Enterprise Linux 
5, SELinux checks memory to ensure that what should be writable is not 
changed to be executable."

The article does the following:
1) Says "SELinux protects against buffer overflow attacks"
2) Describes an attack vector for buffer overflows that was solved in 1992AD,
   which is thus completely irrelevant to the vector the SELinux 
   protection is designed for
3) Makes the incorrect insinuation that SELinux enforces that writable 
areas are not executable.  This is not the case with ExecShield without NX.

> This all works well if all DSOs and PROT_EXEC mappings happen below the 
> executable itself and this is what the ASCII-safe mapping does, as a side 
> effect.  prelink has the option --exec-shield to lay out DSOs at those low 
> addresses.

Wrong on both points.  With every library/binary loaded you have a 
.bss and .data section which are mapped directly after the 
read-only/code sections of the images.  Did you not read the very paper 
you placed a link to?  Take a look at your /proc/<pid>/maps files and 
see if it's only a list of r-x mappings up to a point, then all rw- 
mappings after that point.  It is not.
I draw your attention to the paragraph just before the conclusion where 
it says "After all this protection is applied, the only memory an 
attacker can write to is the stack, the heap, and the data sections of 
the various loaded objects" and here comes the part where ExecShield 
without NX is equated to ExecShield with NX: "unless there are good 
reasons, none of these memory regions is executable"  This is completely 
false in the case of ExecShield without NX: all but the highest-mapped 
DSO will have an executable .bss/.data.  Don't believe me?  Here's it 
again straight from the horse's mouth (Ingo in private mail):

"Here is the situation: with exec-shield we have the
choice of _one_ pair of bss/data section to be non-executable. You are
right that for PIEs we currently pick that library arbitrarily - it's just
the one which happens to be the topmost amongst all libraries (if there is
no high-address mprotect(PROT_EXEC) activity). You are also right that one
better option would be to make the PIE binary itself the 'last' 
library."

Is Ingo wrong also?  He wrote ExecShield -- are you claiming to know it 
better than him?

> I cannot remember anybody ever claiming that this protection is as effective 
> as NX.  It isn't, it never will be.  But for many/most programs we ship it is 

Well which is it?  First you say it's not, then you say it is.  Let me 
clear it up for you:  in one case you have the ability for arbitrary 
code execution, in the other (with SELinux in addition) you do not.  
That's a big difference which is not mentioned in 
http://people.redhat.com/drepper/nonselsec.pdf
as I've just showed above, nor is it mentioned in
http://www.redhat.com/magazine/009jul05/features/execshield/
which specifically says without NX, ExecShield provides "protection 
results comparable to NX technology."
nor is it mentioned in
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
which compares ExecShield's implementation with no NX to PaX's SEGMEXEC 
implementation, when there is no comparison other than the fact that 
they both use segmentation -- the important bit left out being that 
SEGMEXEC actually provides page-granular non-executable pages, while 
ExecShield without NX does not.  It goes further to say "For virtually 
all applications, the kernel places the program code in the lower part 
of virtual memory while keeping the data mostly separate from this 
part."  Using the term "mostly" doesn't acknowledge the fact that the 
.bss/.data for all but one loaded images is executable.

> This still only refers to no-NX.

Hence my subject, and never have I claimed anything to the contrary.  I 
do believe that you're misrepresenting your users however by pretending 
that they all have NX-capable CPUs.  There's a clear sense in any 
available articles on ExecShield that the important details are brushed 
aside and that only NX-capable CPUs are important.  In fact, at:
http://www.redhat.com/magazine/009jul05/features/execshield/
(written in 2005 even, mind you) you'll find the following:
"A year ago it might have been interesting to explore the technical 
details of segment limits, but now that all new processors have NX 
support, segment limit technology is rapidly becoming a relic."
And with that, the situation is ignored.

> The mapping addresses are a policy of the kernel.  The implementation AFAIK 
> always tried to use low addresses for executable mappings.  I really don't 
> see why any of this is supposed to be different from the general DSO-loading 
> task and problem.  If the kernel loads DSOs and PIEs up high, a large portion 
> of the address space is exposed.  Sure.  But if not, the portion is small.  
> And the kernel policy is to do the latter.

You're making no sense.  The .bss/.data are attached to the binary and 
libraries, whether the binary be PIE or not.  Tell me how you keep these 
attached .bss/.data sections residing below the highest mapped image 
(that's all of them but one) from being executable, when they exist 
within the code segment.  You can't, because you're wrong.

> Yes, NULL is a more common invalid address in references.  But it's certainly 
> not the only one.  Until the kernel address space has no execution permission 
> for any of the userlevel data any stray pointer use will be a problem.  

Actually it has nothing to do with no execute for userland data but any 
direct userland access in general, which is what PaX's UDEREF feature 
protects against.  We don't use any of the "solutions" you later go on 
to propose.  UDEREF fully protects against this class of bugs, while 
RedHat does nothing against them.  You've apparently looked at the grsec 
patch -- it's not too hard to do a search for UDEREF and read the 
configuration help for it.

> > is 100% exploitable as a root user (thanks to solar designer,
> > /proc/tty/driver has had its permissions restricted that would have
> > prevented this from being exploitable by a non-root user).
> 
> If you are root, there are easier ways to take over the machine. :)

Root as in uid 0, you know that thing that SELinux is supposed to make 
irrelevant, except in cases like this where you can completely 
compromise the kernel and disable SELinux.  I should hope for SELinux's 
sake that as uid 0 there aren't easier ways to take over the machine.

> Brad, I have a feeling this will always be true. No matter how much you rant, 
> someone will draw a diagram that you won't like. :))

It's easy to draw a correct diagram.  RedHat preferred a misleading one.  
I wonder why?

-Brad

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists