> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/