|Main Archive Page > Month Archives > full-disclosure-uk archives|
On Monday 14 May 2007 10:13, Brad Spengler wrote:
> Take note of their misleading (another word for completely inaccurate)
> diagrams, inability to understand what exactly the new additions to SELinux
> have to do with "buffer overflows,"
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.
> Then there's the design issue RedHat doesn't want you to know about:
> under ExecShield with no NX, every writable mapping lower than the
> highest executable mapping in the address space is executable.
The address space is split into two parts: the lower part which is executable, the higher part which is not. The kernel code dynamically adjust the boundary between the two depending in where DSOs are loaded and PROT_EXEC mappings in general happen. The highest executable mapping decides the boundary.
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.
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 and we could (with some work) show that this is the case at least for the most important programs (network visible, etc).
You can read about it in
section 4, "Implementation Details". That weakness is documented there, so I don't know why you think we don't want people to know.
> For PIE binaries, due to their weaker form of PaX's ASLR, this becomes
> even more interesting since it produces what I call "nondeterministic
> security." Since PIE binaries are treated just like libraries, they
> may or may not be loaded as the highest-mapped library in the system.
> Since there is only one PIE binary loaded and many more libraries being
> loaded, this means that there's a large chance that the bss/data on the
> main executable will be unprotected -- writable and executable.
This still only refers to no-NX.
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.
And all this is completely irrelevant with NX hardware.
> On another note, the following bug fixed in v2.6.21 of the Linux kernel:
> commit fdc30b3d448bf86dd45f9df3e8ac0d36a3bdd9b2
> Author: Taku Izumi <firstname.lastname@example.org>
> Date: Mon Apr 23 14:41:00 2007 -0700
> Fix possible NULL pointer access in 8250 serial driver
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. Userlevel can map pages at all addresses the kernel incorrectly refers to. Randomizing the address of the kernel itself can help a bit but doesn't solve the issue. Nor does disallowing to map at address zero.
> 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. :)
> It's easy to misinform your users when no one questions your
> information. It's harder when the entire security community knows about
> it. I had hoped my previous exploit would have kept RedHat from getting
> away with publishing an article containing the diagram it has, but it
> appears to have not been effective.
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. :))
But I do appreciate your critique.