Re: [Full-disclosure] [Dailydave] What RedHat doesn't want you to know about ExecShield (without NX)
- From: spender@xxxxxxxxxxxxxx (Brad Spengler)
- Date: Mon, 14 May 2007 18:33:37 -0400
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
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'
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
as I've just showed above, nor is it mentioned in
which specifically says without NX, ExecShield provides "protection
results comparable to NX technology."
nor is it mentioned in
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:
(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?
Description: Digital signature
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Prev by Date: [Full-disclosure] [USN-459-1] pptpd vulnerability
- Next by Date: [Full-disclosure] [ MDKSA-2007:104 ] - Updated samba packages fix multiple vulnerabilities
- Previous by thread: Re: [Full-disclosure] [Dailydave] What RedHat doesn't want you to know about ExecShield (without NX)
- Next by thread: Re: [Full-disclosure] What RedHat doesn't want you to know about ExecShield (without NX)