Re: Exec-Shield vs. PaX
On Fri, 7 Nov 2003 12:57, Yven Johannes Leist wrote: Well, I for one would love to see a security announcement one day, which contains something like: All users running the standard Debian kernel are not affected, since the special security features the Debian kernel contains prevent the exploit/attack in question. :) To get this we need support for PIE executables, and preferrably something like ProPolice as well. Currently Debian is behind Fedora and is not showing any signs of catching up... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Exec-Shield vs. PaX
On Sun, Nov 09, 2003 at 08:16:35AM +1100, Russell Coker wrote: On Fri, 7 Nov 2003 12:57, Yven Johannes Leist wrote: Well, I for one would love to see a security announcement one day, which contains something like: All users running the standard Debian kernel are not affected, since the special security features the Debian kernel contains prevent the exploit/attack in question. :) To get this we need support for PIE executables, and preferrably something like ProPolice as well. Currently Debian is behind Fedora and is not showing any signs of catching up... We'd need a hell of a lot more evidence of PIE's value before I'd let anyone inflict that on Debian by default. It's both dubious and a nuisance to developers, since it increases irreproducibility. It's also still what I would consider experimental. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Exec-Shield vs. PaX
Scripsit Yven Johannes Leist [EMAIL PROTECTED] Well, I for one would love to see a security announcement one day, which contains something like: All users running the standard Debian kernel are not affected, since the special security features the Debian kernel contains prevent the exploit/attack in question. :) Hm, what I've been able to glean from the discussions seems to imply that any software that's vulnerable to a remote access exploit *without* the kernel-level protection in question, would still at least be vulneable to a DoS attack, killing the server (or whatever) process instead of giving the attacker actual control. So we'd still want to provide security updates to the same extent as without. -- Henning Makholm Hele toget raslede imens Sjælland fór forbi.
Re: Exec-Shield vs. PaX
The test incorrectly assumes that thread stacks are executable is not equivalent to thread stacks are non-executable. And there's no conflict in what i say above. ok, i was quoting too much and you interpreted the wrong part. the bit i was referring to is this: I suspect we both agree that it's desirable to have thread stacks non-executable as well. on one hand you acknowledge that it's better to have non-exec thread stacks but on the other hand you argued that it's not a bugfix to break apps that rely on an executable stack - the stack _is_ executable. ^ as they say, you can't have it both ways. also, the test does not only demonstrate that thread stacks are executable or not, it demonstrates a fundemental design flaw in Exec-Shield: whenever an executable region is created in the address space, *everything* below that becomes executable as well. [...] thanks, the cat is finally out of the bag - you admit here that the incriminating paxtest code is there to demonstrate what you characterise as a flaw in exec-shield. the cat has always been out of the bag, way back in my very first mail in this thread (and it's now the second time i've quoted this bit): Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable the above changes are the result of Ingo's approach to create non-executable memory on i386, they're not per page as a simple mprotect on the top of the stack shows. before i get accused of specifically rigging the tests, i'll tell you that running multithreaded apps would have almost the same effect (only the main stack would stay non-exec under Exec-Shield). needless to say, PaX passes all the above as before. since you have such a problem with paxtest doing the explicit mprotect() itself i decided to change it to a simple nested function, it will achieve the same and hopefully satisfy you as well. Note that none of your arguments tries to claim that any real application indeed does mprotect(argv), which is pretty telling by itself. indeed. if you read my mails again (i'm getting tired of quoting myself all over again), i told you explicitly what paxtest is for: testing for regressions, situations when stuff fails. Exec-Shield fails under the above mentioned situation. it also fails when gcc nested functions are used, you'll see that in 0.9.6. i hope you won't argue that no real application uses nested functions (and before you object even to that, as you said yourself, nested functions are just one way to trigger the heuristics in gcc, other code constructs from real life would do the same as well). As i have explained it a hundred times, this behavior is a well-known property of exec-shield, and that we've done a quite good job of reducing this effect. In fact i've put it into my exec-shield announcement: *none* of your public postings discusses the inherent problem with memory regions becoming executable when something above them does. the quote from your README talks about the ascii-armor region and data being executable in there. it does not talk about how the main application's data or the heap or even the entire stack can become unexpectedly executable. on a related note, PT_GNU_STACK support as implemented in Exec-Shield suffers from the same problem: you make not only the stack executable but *everything* else below it, i could not find a note from you talking about it. ( sorry, but i'm going to stop contributing to this thread. You are getting increasingly irrational and emotional, there's nothing more i could add to this thread. I do acknowledge that PaX is more secure, but i also say that exec-shield is a hell alot of a difference from a stock distro. You expressed your feelings that exec-shield is insecure in one area and apparently you conclude that it's thus useless. There's nothing i can do to change this irrational bad logic of yours. ) Ingo, if you read one of my previous posts, you will realize that i did say that Exec-Shield was mostly good enough against current exploit methods (which blindly expect their injected payload to be executable). what it's not good enough for is protecting against future attacks which will (because they can) adapt and circumvent Exec-Shield in certain cases. this is not true for PaX and obviously that decides what i'm going to use (and have been for all these past 3 years). and finally on a personal note: you're quick to call people by names, that's not professional especially when none of the facts support your position. --- i was not cc'd on this, but i'd still like to reply here: Henning Makholm said: Hm, what I've been able to glean from the discussions seems to imply that
Re: Exec-Shield vs. PaX
On Fri, Nov 07, 2003 at 12:15:06PM +0100, [EMAIL PROTECTED] wrote: | I suspect we both agree that it's desirable to have thread stacks | non-executable as well. | | on one hand you acknowledge that it's better to have non-exec thread | stacks but on the other hand you argued that | | it's not a bugfix to break apps that rely on an executable stack - the | stack _is_ executable. | ^ | | as they say, you can't have it both ways. He's saying that there's no reason to have an executable stack for programs which never attempt to execute code on the stack---and having a non-executable stack in such circumstances gives you a security advantage---but it is not okay for the operating system to break those programs which /do/ rely on the stack being executable. Now could you please stop wasting everybody's time by continuing this thread? Ingo has already stated that he won't continue arguing with you, and I don't intend to continue posting in this thread after this message either. Cameron.
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote: [...] also, you did break userland yourself as well, otherwise how would you explain the patches RedHat made to the XFree86 server? actually, unmodified XFree86 works just fine. It will have an executable stack but it will work out of box - so no app was broken. tuxracer works out of box as well. X does break if you force exec-shield=2, and it did break even with exec-shield=1 in earlier iterations of exec-shield, but that bug has been fixed. the XFree86 patching you refer to above we did was to enable non-exec stack. But this was an iterative thing to enhance security, not something we had to do because X broke due to exec-shield itself. Ingo
Re: Exec-Shield vs. PaX
[...] also, you did break userland yourself as well, otherwise how would you explain the patches RedHat made to the XFree86 server? actually, unmodified XFree86 works just fine. It will have an executable stack but it will work out of box - so no app was broken. false! my unmodified X server (gentoo) dies with the following core when trying to run it under [1]: (gdb) bt #0 0x00caf471 in kill () from /lib/libc.so.6 #1 0x00caf215 in raise () from /lib/libc.so.6 #2 0x00cb07bb in abort () from /lib/libc.so.6 #3 0x0806eb99 in AbortDDX () #4 0x080ed43a in FatalError () #5 0x0808522c in xf86SigHandler () #6 signal handler called #7 0x0a226000 in ?? () #8 0x080a6f98 in LoadModule () #9 0x0806fa3c in xf86LoadModules () #10 0x0806db2a in InitOutput () #11 0x080d36c1 in main () does LoadModule() ring a bell? why don't you realize that there's a world beyond RedHat and that you *do* break those people's system? heck, you did break RedHat users' systems as well, you say so yourself: [2] or [3]. every time you suggest that a user upgrade X means that you have broken his existing binary - a clear no-no by your own rules. X does break if you force exec-shield=2, and it did break even with exec-shield=1 in earlier iterations of exec-shield, but that bug has been fixed. excerpt from [1]: --- linux/kernel/sysctl.c.orig +++ linux/kernel/sysctl.c @@ -52,6 +52,9 @@ extern int core_uses_pid; extern char core_pattern[]; extern int cad_pid; +int exec_shield = 2; +int exec_shield_randomize = 1; that to me means that *everyone* will have his *existing* binary broken, by your own admission. it also means that you have violated the very rule of Linus you had referred to before. the XFree86 patching you refer to above we did was to enable non-exec stack. But this was an iterative thing to enhance security, not something we had to do because X broke due to exec-shield itself. XFree86 never needed an executable stack as far as i know, what was there to 'enhance' then? it is clear that XFree86 did break because of Exec-Shield and you had to modify both to get it to work and be able to claim that it works out of the box. incidentally, if i were to make use of PT_GNU_STACK in PaX, i could claim the same - now what was your point of fighting this silly issue? by the way, on another look at your patch i noticed the following: 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables() but don't make use of it, probably it's not needed at all now. 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state between mpnt-vm_page_prot and mpnt-vm_flags, the former should be derived from the latter, just like do_mmap_pgoff() does it. [1] http://people.redhat.com/mingo/exec-shield/exec-shield-2.4.22-G4 [2] http://marc.theaimsgroup.com/?l=linux-kernelm=106482772021534w=2 [3] http://marc.theaimsgroup.com/?l=linux-kernelm=106502603232695w=2
Re: Exec-Shield vs. PaX
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote: actually, unmodified XFree86 works just fine. It will have an executable stack but it will work out of box - so no app was broken. false! my unmodified X server (gentoo) dies with the following core when trying to run it under [1]: you need to update your gcc, glibc and binutils chain and change exec-shield=1 (all the code is available under the GPL) to get a fully compatible exec-shield solution. the patches on my site default to exec-shield=2. exec-shield=2 means blanket non-exec stacks for _every_ binary. You are trying to make a big fuss about this for no good reason. My patches default to 2 to get wider testing without having to recompile all of userspace. (but recompiling all of userspace shouldnt be an issue on your gentoo box.) X does break if you force exec-shield=2, and it did break even with exec-shield=1 in earlier iterations of exec-shield, but that bug has been fixed. excerpt from [1]: +int exec_shield = 2; Look at the Fedora Core 1 distribution released yesterday to see the complete solution - there exec-shield defaults to 1. You need PT_GNU_STACK markings for all apps to work under exec-shield. It cannot be solved via a single kernel patch. If exec-shield is to be added to Debian then this should be done too. Ingo
Re: Exec-Shield vs. PaX
You are trying to make a big fuss about this for no good reason.
Ingo, please. it was *you* who objected to PaX's default enforcement
policy because it broke Linus's rule. yet you did the same with your
own default *and* contested the fact that you hadn't broken anything.
i don't have a problem with your choice for default policies, i have
a problem when you have a double standard ('kettos merce' in your
mother tongue).
Re: Exec-Shield vs. PaX
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote: [...] incidentally, if i were to make use of PT_GNU_STACK in PaX, i could claim the same - now what was your point of fighting this silly issue? yes, this was precisely my point to discuss this issue. Executability of the stack is not some divine privilege given to the sacred few, distributed via matters of public policy determined by the ruler of the system, it's simply a property of the code written. The system ought to detect it automatically and not stand in the way. We implemented the code for this - and the compiler, toolchain and glibc supports it all across. If PaX makes use of PT_GNU_STACK [just take the binfmt_elf.c bits] then this portion of PaX will conform to the Linus rule too. This is not some magic property only attached to exec-shield. this is i believe the main goal, in the quest to bring security to the average user. The only way to do that is to concentrate all technology on making security as automatic and hassle-free as possible. i hope we've finally settled this issue, right? You might still think of me in unfavorable terms but i've got to live with that :-) by the way, on another look at your patch i noticed the following: 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables() but don't make use of it, probably it's not needed at all now. 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state between mpnt-vm_page_prot and mpnt-vm_flags, the former should be derived from the latter, just like do_mmap_pgoff() does it. thanks, i'll fix these! Ingo
Re: Exec-Shield vs. PaX
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote: there's nothing wrong about an executable stack though. It's been part of Linux ever since. the brk() managed heap has also been executable. yet you break apps that assume so (the ominous XFree86 server would also use the brk() managed heap if you were to tell malloc() to not use mmap() at all or for 'big' areas only, well beyond the default 128k. actually, for 'small' modules XFree86 does use the brk() heap). yes. This is one reason why exec-shield isnt ready for the mainline kernel (and might never be). Fortunately, executable malloc() assumptions seem to be much less widespread than the reliance on an executable stack. But you are right of course, exec-shield breaks the 'Linus rule' too. Ingo
Re: Exec-Shield vs. PaX
[...] randomization serves NO purpose in the grand scheme, it does not provide guaranteed protection against the PaX attack model (arbitrary read/write access to the address space). [...] there's another, practical aspect of address-space randomization which i find to be the most important: to make worms uneconomic in network bandwidth terms. having non-executable pages achieves the same *and* guarantees failure (vs. the probabilistic failure/success rate of randomization), that's why i said that randomization played no role 'in the grand scheme'. the fact it's still useful these days is the consequence of our inability to effectively protect against the attack methods 2 and 3 i had referred to earlier (luckily for the defense side, existing worms have used attack method 1 but i would not rely on that in the future). i took the 'they are broken for good' as equivalent to 'concepts flawed by design', and 'important privilege that should be carefully managed' as a signal of your belief that the ability to generate code should be restricted. I do not agree with this direction. 'they are broken for good' means just that, they are no longer able to run under PaX without tagging (at least not when PaX is configured in its optimal form, that is, with non-exec pages and MPROTECT on). you're correct with what i meant by 'managed' although i think you may not like it because of the choice of my wording, not because what i meant. if i say 'we need an API to allow userland to generate code at runtime', will you still disagree with that (meaning 'disagree on principles', not the suggested implementation)? The moment you start to 'manage' stuff that you believe is 'broken for good' it ends up being less accessible to people. 'root for everyone!' - isn't that concept 'broken for good' (in the sense you originally interpreted it, i.e., 'flawed by design')? see, we do change systems to be able to 'manage stuff' even if that means that we'll make that stuff 'less accessible to people' (how many times do system admins have to do things on behalf of their users because said users are now not allowed to do it themselves?). so what am i getting at here? the fact that secure (heck, even just usable) systems should follow the principle of 'least privilege'. in the multi-user system case, it says (among others) that if a user does not need to have the privilege of root (read: complete system control), then he should not have it, hence we have the concept of UIDs (and capabilites, as the case may be). in the PaX memory protection case it means that if an application does not need the privilege to generate code at runtime, then it should not have it. interestingly enough, this is exactly what i say in [3] - did you read/understand it? if you did, then you should have realized that you can argue only about whether you want to follow a least privilege policy in this case, you cannot argue about how to do it because there's just one way (the memory protection concept of PaX). I would like to see all these security technologies to show up on Joe Average's desktop, so government-style manual need-to-know access control just doesnt cut it. It might work if packaged very very carefully with lots of care towards making it simple, but i see zero efforts in that direction. i would not call [1] or [2] 'zero efforts'. you said a lot about what you don't agree with in PaX, what exactly prevented you from changing it *yourself*? what prevents *you* from disabling MPROTECT by default for example? we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did seem to be a reasonable person with tons of experience and this matters alot when considering patches) and the killer at that time was the 1.5 GB VM limitation on x86. Exec-shield, as coarse as it might be, does here and today offer quite acceptable non-executability coverage of all actual apps we checked, and this is what counts. (Nobody puts bogus mprotect(argv) calls into these apps to disable exec-shield so exec-shield just works.) [...] the mprotect argument came not from my ability to enable or disable it in PaX, but from the claim/impression that the (mprotect) tests in paxtest constitude actual 'Vulnerabilities'. So i simply said i dont intend to restrict mprotect semantics in exec-shield and explained my reasons for doing so. i'm sorry that you still haven't realized what PaX/paxtest are about. PaX works against *exploit*methods* and paxtest simulates the core steps of those methods to determine to what extent they work on a given system. what you call 'bogus' again shows your misunderstanding of how one writes exploits. let's do some thinking: why did you write Exec-Shield (non-exec pages, randomization)? to make exploit methods non-working. now the question is, have you achieved that goal or not? or a bit harder question: what did you achieve exactly? my answers are below: Exec-Shield prevents existing exploits that
Re: Exec-Shield vs. PaX
It is in fact a simulation of a multithreaded application. [...] The test incorrectly assumes that thread stacks are executable. I suspect we both agree that it's desirable to have thread stacks non-executable as well. while i agree with you on this one, it is in stark contrast to what you said earlier: there's nothing wrong about an executable stack though. It's been part of Linux ever since. also, the test does not only demonstrate that thread stacks are executable or not, it demonstrates a fundemental design flaw in Exec-Shield: whenever an executable region is created in the address space, *everything* below that becomes executable as well. i believe it is important that Exec-Shield users are aware of this flaw, could you write a test for this as well please?
Re: Exec-Shield vs. PaX
On Thu, 6 Nov 2003 [EMAIL PROTECTED] wrote: The test incorrectly assumes that thread stacks are executable. I suspect we both agree that it's desirable to have thread stacks non-executable as well. while i agree with you on this one, it is in stark contrast to what you said earlier: there's nothing wrong about an executable stack though. It's been part of Linux ever since. sorry but i really have to say that your logic is flawed. (It's sad to see when a discussion deteriorates to such a stage and i've decided to stop it from my side, see more below. [ thousands of debian-devel readers rejoice :-) ] ) The test incorrectly assumes that thread stacks are executable is not equivalent to thread stacks are non-executable. And there's no conflict in what i say above. all i'm saying is that each and every application has a fair right to assume an executable stack. _If_ tools find (or developer asserts it, in the source) that a particular application does _not_ need an executable stack then it's perfectly fine for the OS to go for it and enable a non-executable stack! you should not do this decision for the application/library in one way or another. also, the test does not only demonstrate that thread stacks are executable or not, it demonstrates a fundemental design flaw in Exec-Shield: whenever an executable region is created in the address space, *everything* below that becomes executable as well. [...] thanks, the cat is finally out of the bag - you admit here that the incriminating paxtest code is there to demonstrate what you characterise as a flaw in exec-shield. Note that none of your arguments tries to claim that any real application indeed does mprotect(argv), which is pretty telling by itself. As i have explained it a hundred times, this behavior is a well-known property of exec-shield, and that we've done a quite good job of reducing this effect. In fact i've put it into my exec-shield announcement: # Limitations: # # # also, if the overflow is within the exec-shield itself (e.g. within the # data section of one of the shared library objects in the ASCII-armor) # then the overflow might be possible to exploit. # # [...] # All in one, exec-shield is one barrier against attacks, not blanket 100% # protection in any way. The most efficient security can be provided by # installing as many layers as possible. But you dont have to believe me, you can try it yourself, install an exec-shield distro and measure the effect of this exec-shield property. ( sorry, but i'm going to stop contributing to this thread. You are getting increasingly irrational and emotional, there's nothing more i could add to this thread. I do acknowledge that PaX is more secure, but i also say that exec-shield is a hell alot of a difference from a stock distro. You expressed your feelings that exec-shield is insecure in one area and apparently you conclude that it's thus useless. There's nothing i can do to change this irrational bad logic of yours. ) Ingo ps. for those who'd like to get rid of this thread too, put this into your .procmailrc: :0: * ^Subject:.*Exec-Shield vs. PaX /dev/null
Re: Exec-Shield vs. PaX
On Wednesday 05 November 2003 07:28, Graham Wilson wrote: On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] [...] Please, guys, don't have your discussion here. I don't think we really care about the differences between PaX and exec-shield. Debian is not, and, to the best of my knowledge, will not, choose one for its kernels, so there is no need to prove that one or the other is better. Well, I for one would love to see a security announcement one day, which contains something like: All users running the standard Debian kernel are not affected, since the special security features the Debian kernel contains prevent the exploit/attack in question. :) Cheers, Yven -- Yven Johannes Leist - [EMAIL PROTECTED] http://www.xnap.org/leist/
Re: Exec-Shield vs. PaX
On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] [...] Please, guys, don't have your discussion here. I don't think we really care about the differences between PaX and exec-shield. Debian is not, and, to the best of my knowledge, will not, choose one for its kernels, so there is no need to prove that one or the other is better. -- gram signature.asc Description: Digital signature
Re: Exec-Shield vs. PaX
On Wed, Nov 05, 2003 at 12:28:51AM -0600, Graham Wilson wrote: | Please, guys, don't have your discussion here. I don't think we really | care about the differences between PaX and exec-shield. Debian is not, | and, to the best of my knowledge, will not, choose one for its kernels, | so there is no need to prove that one or the other is better. Why should it not? If Pax or Exec-shield can be added to the kernel without breaking things, and provide better protection against some types of security holes than a default kernel, then surely there is a case to be made for including one or the other in the stock Debian kernel. (Without breaking things is the tricky bit here, of course.) Cameron.
Re: Exec-Shield vs. PaX
On Wed, Nov 05, 2003 at 12:28:51AM -0600, Graham Wilson wrote: On Wed, Nov 05, 2003 at 02:49:39AM +0100, Ingo Molnar wrote: On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: [...] [...] Please, guys, don't have your discussion here. I don't think we really care about the differences between PaX and exec-shield. Debian is not, and, to the best of my knowledge, will not, choose one for its kernels, so there is no need to prove that one or the other is better. The requested debian-kernels new ML will be the perfect place to start this kind of flame wars :) In the meantime I'm afraid there is not another list, but for d-d, where discussion on this kind of things can be accepted. -- Francesco P. Lovergine
Re: Exec-Shield vs. PaX
[metanote: as you can see, we're entering the meta-discussion part and i can very well understand that it's of little if any interest to most you (that includes me btw), so i'll try not to post more here except maybe to discuss technical issues] 1. 'It seems that exec-shield does 99% of what PaX does' this is not the case and i'm not claiming it. If you feel attacked, please dont - i'll stipulate that PaX gives better security than exec-shield, ok? in case you didn't realize it, it was not directed at you either. - PaX implements perfect non-executable pages on amd64, i386, ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has some imitation of it only on i386 (it's not true per-page). non-executable pages on anything else but i386 is a triviality, as the hardware and the kernel supports it. There's virtually nothing that PaX or exec-shield has to add to enable them - they are there. that's what you say because apparently you have never checked it let alone tried. here's a few of these 'trivial' questions for you to answer: 1. how do you do per page non-exec pages on ppc/ppc64? hint, there's no NX bit in their PTE format. try to answer that without looking at PaX first ;-) 2. how do you do per page non-exec pages on mips/mips64? hint, there's no split TLB (let alone NX PTE bit) in the base architecture definition. 3. how do you do per page non-exec pages on sparc64 under linux 2.6? hint, you've reused the last free bit in the PTE. and linux didn't support NX on sparc64 even before 2.6. 4. how do you do per page non-exec pages on sh[34]? hint, there's at most a 'half' split TLB only and no NX PTE bit. 5. how do you do per page non-exec pages without a TLB/MMU (you did claim 'trivial' support for anything but i386)? next, what will you do with the archs where the .plt is in the rwx ELF segment and hence under your scheme would force all of .data/.bss to become executable as well? lets also point out that exec-shield offers relative randomization of DSOs to each other, while PaX only randomizes a single base of the DSOs, their relative addresses remain constant. This way the randomization bits of exec-shield add up for brute-force attacks. Lets add it that if a limited exploit can be turned into an information leak then relative randomization does not help - but it does help if the first exploit itself needs precise addresses from multiple DSOs. all correct, except for the fact that the whole exercise of per-library randomization is pointless. i say that based on my experience in analyzing bugs and writing exploits for them - admittedly something i can't share with you, so feel free to think otherwise. what i can offer however is a simple observation: if an attacker needs code addresses from more than one library, then he can get them even under Exec-Shield. this is because he can just use the .plt entries of the library whose base address he learned via info-leaking. also, the most likely information leaks that contain library addresses are on the stack - and you can imagine that the stack will likely contain such addresses from more than one region, hence there's little if any advantage of separate randomization. in any case, you're missing the point behind randomization. it's an obscurity feature, however efficient it may turn out to be in certain cases. i did it because it was extremely cheap (speaking of the PaX implementation, not Exec-Shield) so i said 'why not'. randomization serves NO purpose in the grand scheme, it does not provide guaranteed protection against the PaX attack model (arbitrary read/write access to the address space). you don't have an attack model so you can say whatever you want about the details of your randomization, they will of course be 'true' by definition. second, paxtest had some bugs which Exec-Shield exposed and made Exec-Shield appear better than it is. i've fixed them here and expect to release 0.9.5 today or so. the results now look like: ( how fair that you give me a chance to run it ... not. ) from the email headers of your answer: Date: Wed, 5 Nov 2003 00:58:30 +0100 (CET) From: Ingo Molnar [EMAIL PROTECTED] paxtest 0.9.5 was released hours (!) before that, what are you talking about? (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program order with arbitrary data no. no what? are you telling me you know of an exploit technique against a memory corruption bug that does not belong to any of the above categories? because that's what my statement was about. No offense meant, but i say so because right now i dont see the way to have a generic and usable Linux system with all the restrictions you are talking about. If you complete your project and everything works and it's still the same live, flexible and kicking Linux system that we all know and love then i was clearly
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote: i downloaded the new 0.9.5 paxtest package and amongst other changes it has the following oneliner change: [...] + do_mprotect((unsigned long)argv ~4095U, 4096, PROT_READ|PROT_WRITE|PROT_EXEC); first of all, it's multithreaded. [...] paxtest does not link to libpthread, nor does it create threads, at all. How can you claim it's multithreaded? glibc creates executable thread stacks by default. [...] to the contrary, glibc does this: 00594000-005a1000 r-xp 09:00 735400 /lib/tls/libpthread-0.60.so 005a1000-005a2000 rw-p c000 09:00 735400 /lib/tls/libpthread-0.60.so 005a2000-005a4000 rw-p 00:00 0 0063b000-0065 r-xp 09:00 730361 /lib/ld-2.3.2.so 0065-00651000 rw-p 00015000 09:00 730361 /lib/ld-2.3.2.so 00e25000-00f58000 r-xp 09:00 735396 /lib/tls/libc-2.3.2.so 00f58000-00f5b000 rw-p 00132000 09:00 735396 /lib/tls/libc-2.3.2.so 00f5b000-00f5e000 rw-p 00:00 0 08048000-08049000 r-xp 09:02 5226629/tmp/test 08049000-0804a000 rw-p 09:02 5226629/tmp/test 09e9c000-09ebd000 rw-p 00:00 0 beba6000-beba7000 ---p 00:00 0 == thread stack guard page beba7000-bf5a8000 rw-p 1000 00:00 0 == non-exec thread stack bf5be000-bf5bf000 rw-p 00:00 0 bfe79000-c000 rw-p fff5d000 00:00 0 $ rpm -q glibc glibc-2.3.2-101 Ingo
Re: Exec-Shield vs. PaX
first of all, it's multithreaded. [...] paxtest does not link to libpthread, nor does it create threads, at all. How can you claim it's multithreaded? i did not. if you quote my post like this: let me get back to the topic of java as i promised above. java is a nice animal as it shows several issues with Exec-Shield. first of all, it's multithreaded. glibc creates executable thread stacks by default. [...] it will be clear that i was referring to java. glibc creates executable thread stacks by default. [...] to the contrary, glibc does this: [snip] $ rpm -q glibc glibc-2.3.2-101 that's what RedHat's glibc does. and this is what i get on gentoo (again, sorry for the plug, although i think other distros like debian would show the same as well): $ epm -q glibc glibc-2.3.2-r8 excerpt from the maps file of /opt/blackdown-jdk-1.4.1/bin/java (running under PaX but without non-exec pages, randomization was still on): b7b7f000-b7b8 +++p 00:00 0 b7b8-b7b8e000 RWXp 1000 00:00 0 b7b8e000-b7b91000 +++p f000 00:00 0 b7b91000-b7c0 RWXp 00012000 00:00 0 b7d7f000-b7d8 +++p 00:00 0 b7d8-b7d8e000 RWXp 1000 00:00 0 b7d8e000-b7d91000 +++p f000 00:00 0 b7d91000-b7e0 RWXp 00012000 00:00 0 b7f7f000-b7f8 +++p 00:00 0 b7f8-b800 RWXp 1000 00:00 0 b850-b850a000 RWXp 00:00 0 b850a000-b850d000 +++p 00:00 0 b86f2000-b86fb000 RWXp 8000 00:00 0 regardless of whether RedHat fixed this or not (i hope it will enter the main glibc tree btw), the fundemantal problem of changing memory protections without asking stays there (LinuxThreads was just one known way to trigger it).
Re: Exec-Shield vs. PaX
Hi! this intentionally calls mprotect(PROT_EXEC) for the highest possible address one can think of. This call has no useful purpose at all. In other words, this is a specific, underhand cheat to trigger 'Vulnerable' messages for all items when running paxtest on exec-shield kernels. Bravo! If you get bad grades on school, don't work harder, blame the teacher. Other people have been asking for such a test, because there was speculation about this vulnerability in exec-shield. It is in fact a simulation of a multithreaded application. I objected to adding tests that include a multi- threaded library, because the library might interfere with the results of the test. So instead of adding a library that would perform the mprotect(), the mprotect() itself was added. Since multi-threaded applications are not that uncommon. Therefore the results are quite relevant I think. People deserve to know what the limitations the security products they use have. That is why the return to function tests have been included, to show that PaX is good but not perfect. Paxtest simply shows if people tell the truth about memory protection patches. I wrote it to see if what pageexec told me about it was true or not, so I wouldn't lie to people when I tell them Adamantix has good memory protection. There are already too many lies in the security world that there is no need for even more. And after all, if exec-shield is being included in the Debian default kernel source, then you are talking about the pride of a 1000 developers that are at stake here. That is not something you should take lightly if you ask me. :-) frankly, i've never experienced anything like this in my many years in the Linux world. You so far gave the impression of a reasonable and balanced person but this is as low as it gets. Shame on you. Do you have the detailed specification of exec-shield somewhere? That would make it easier to evaluate the completeness of the test suite. Feel free to submit tests yourself, I'll add any sensible test. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003, Peter Busser wrote: And after all, if exec-shield is being included in the Debian default kernel source, then you are talking about the pride of a 1000 developers that are at stake here. That is not something you should take lightly if you ask me. :-) You mean the single developer who maintains the standard debian kernel, or the single developer who maintains the execshield or pax patches.
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote: glibc creates executable thread stacks by default. [...] to the contrary, glibc does this: [snip] $ rpm -q glibc glibc-2.3.2-101 that's what RedHat's glibc does. [...] yes. The changes are in mainline glibc, everyone will pick those changes up with time. Ingo
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003, Peter Busser wrote:
It is in fact a simulation of a multithreaded application. [...]
The test incorrectly assumes that thread stacks are executable. I suspect
we both agree that it's desirable to have thread stacks non-executable as
well.
I objected to adding tests that include a multi- threaded library,
because the library might interfere with the results of the test.
in fact it's desirable to properly have the same 'effect' a pthread
library has - after all that 'effect' might have security relevance. The
best way to do that is to use the threading library used by virtually all
applications on the box where the test is running: -lpthread.
[...] Feel free to submit tests yourself, I'll add any sensible test.
yep, proper threaded test added. This should put this episode to rest.
Ingo
diff -rNu paxtest-0.9.5/body.c paxtest-0.9.5/body.c
--- paxtest-0.9.5/body.c
+++ paxtest-0.9.5/body.c
@@ -13,6 +13,13 @@
#include signal.h
#include sys/types.h
#include sys/wait.h
+#include pthread.h
+
+static void *test_thread(void *p)
+{
+pause();
+return NULL;
+}
#ifndef PAGESIZE
#define PAGESIZE (4096)
@@ -29,8 +36,13 @@
fflush( stdout );
if( fork() == 0 ) {
- do_mprotect((unsigned long)argv ~4095U, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC);
+ pthread_t thread;
+
+ pthread_create(thread, NULL, test_thread, NULL);
+
doit();
+
+ pthread_kill(thread, SIGTERM);
} else {
wait( status );
if( WIFEXITED(status) == 0 ) {
diff -rNu paxtest-0.9.5/Makefile.generic paxtest-0.9.5/Makefile.generic
--- paxtest-0.9.5/Makefile.generic
+++ paxtest-0.9.5/Makefile.generic
@@ -2,7 +2,7 @@
CC=gcc
CFLAGS=-O2
-LDFLAGS=
+LDFLAGS=-lpthread
ifndef RUNDIR
RUNDIR=.
endif
Re: Exec-Shield vs. PaX
On Wed, 5 Nov 2003 [EMAIL PROTECTED] wrote: non-executable pages on anything else but i386 is a triviality, as the hardware and the kernel supports it. There's virtually nothing that PaX or exec-shield has to add to enable them - they are there. You are right that the other architectures you listed need alot of nontrivial work and PaX did it very nicely. The two architectures that will likely capture more than 90% of the CPU market in the next 10 years, ia64 and amd64 both have executable bits in their pte formats. These need no extra work. My sentence above should be any of the x86 successors, instead of anything else. [ i accept your points wrt. relative randomization. ] [...] randomization serves NO purpose in the grand scheme, it does not provide guaranteed protection against the PaX attack model (arbitrary read/write access to the address space). [...] there's another, practical aspect of address-space randomization which i find to be the most important: to make worms uneconomic in network bandwidth terms. The most effective worm in recent history was a single-packet exploit-and-infect attack, with a high likelyhood to infect a machine via that single packet. If the worm has to guess certain exploit parameters then the introduction of just one other packet can make or break the dynamics of worm propagation - let alone the need for 1024 or 32K packets for a single infection. So randomization does have an important longterm significance. i agree that it's near worthless against local attacks or directed attacks. It might help in eventually bringing more attention to the attack itself but that's not a guarantee. second, paxtest had some bugs which Exec-Shield exposed and made Exec-Shield appear better than it is. i've fixed them here and expect to release 0.9.5 today or so. the results now look like: ( how fair that you give me a chance to run it ... not. ) i take this back - you did offer it for download. (I was parsing 'today or so' as 'sometime later' and didnt check your site. I did check it after sending the mail and discovered the new package. Obviously my points wrt. the 'threading change' remain.) you do realise that most of those 'exploit techniques' overlap with some programming concepts, and you think that those concepts are flawed by design and should be eliminated - i dont agree with this characterisation. putting words into my mouth or can you actually quote me on that? i did not intend to put anything in your mouth - this is how i understood your paragraph below: - apps that by their nature want to generate code runtime (e.g., java). they're broken for good which many people noticed by now. that's good, that was my purpose because i wanted to draw attention to the fact that runtime code generation is an important privilege that should be carefully managed (as it happens to be also one of the exploit techniques). i took the 'they are broken for good' as equivalent to 'concepts flawed by design', and 'important privilege that should be carefully managed' as a signal of your belief that the ability to generate code should be restricted. I do not agree with this direction. The moment you start to 'manage' stuff that you believe is 'broken for good' it ends up being less accessible to people. (let me know if you think this is an unfair/inaccurate characterisation of your words.) what i'm saying is that there are programming techniques (runtime code generation in this case) that should be handled more carefully than they have been. what PaX does by default FOR NOW is the result of me being cautious (and i have not heard of a single PaX user yet who did not appreciate it) and not having the resources to fix up userland all by myself. [...] my experience is that resources that get 'managed' manually tend to be much less accessible to the average user. Scripting (which is a form of code generation) and generally writing code is the heart of Linux. I would like to see all these security technologies to show up on Joe Average's desktop, so government-style manual need-to-know access control just doesnt cut it. It might work if packaged very very carefully with lots of care towards making it simple, but i see zero efforts in that direction. In fact i got flamed for even mentioning PT_GNU_STACK which i believe is one careful step in that direction. you said a lot about what you don't agree with in PaX, what exactly prevented you from changing it *yourself*? what prevents *you* from disabling MPROTECT by default for example? we did take a look at the PAX_SEGMEXEC portion of PaX for Fedora (you did seem to be a reasonable person with tons of experience and this matters alot when considering patches) and the killer at that time was the 1.5 GB VM limitation on x86. Exec-shield, as coarse as it might be, does here and today offer quite acceptable non-executability coverage of
Exec-Shield vs. PaX
since a few points have been made regarding $subject, let me clear up a few of them: 1. 'It seems that exec-shield does 99% of what PaX does' i don't know the origin of that number above, for now i'll just stick to the facts i know: - PaX implements perfect non-executable pages on amd64, i386, ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has some imitation of it only on i386 (it's not true per-page). - PaX implements a concept about how runtime code generation should be done, there's nothing similar in Exec-Shield, and it seems that Ingo does not even understand why this is important (for Ingo: please read and understand [1] before you call something bogus, see below for more). - PaX implements best-effort randomization of the entire address space, Exec-Shield does it too but at a higher code complexity and a lower entropy rate while having a worse effect on the kernel entropy pool. 2. paxtest 'proofs' i saw several people point to paxtest results to 'prove' how good Exec-Shield it is. it is not. first, Exec-Shield has a fundamental design problem stemming from the lack of understanding or design on Ingo's part (what i call MPROTECT in PaX). you'll really have to read the PaX design docs to understand its role in the grand scheme of things (see below for a bit more). second, paxtest had some bugs which Exec-Shield exposed and made Exec-Shield appear better than it is. i've fixed them here and expect to release 0.9.5 today or so. the results now look like: PaXtest - Copyright(c) 2003 by Peter Busser [EMAIL PROTECTED] Released under the GNU Public Licence version 2 or later It may take a while for the tests to complete Test results: PaXtest - Copyright(c) 2003 by Peter Busser [EMAIL PROTECTED] Released under the GNU Public Licence version 2 or later Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable the above changes are the result of Ingo's approach to create non-executable memory on i386, they're not per page as a simple mprotect on the top of the stack shows. before i get accused of specifically rigging the tests, i'll tell you that running multithreaded apps would have almost the same effect (only the main stack would stay non-exec under Exec-Shield). needless to say, PaX passes all the above as before. Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect): Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Executable stack (mprotect) : Vulnerable Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC): 13 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test: 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) Return to function (strcpy) : Vulnerable Return to function (strcpy, RANDEXEC): Vulnerable Return to function (memcpy) : Vulnerable Return to function (memcpy, RANDEXEC): Vulnerable Executable shared library bss: Vulnerable Executable shared library data : Vulnerable these two had bugs in them (they were trying to execute code from the wrong location). i find it somewhat funny that the Exec-Shield proponents (including Ingo himself) have used the previous false results as a justification for their claims. apparently none of you understood what the tests and Exec- Shield did, otherwise you would have known that Exec-Shield cannot possibly pass these tests due to its design (or at least not without going down the OpenBSD road). Writable text segments : Vulnerable 3. MPROTECT is bogus it is not. Ingo says so because he did not understand how PaX works. the short story (there's no substitute to reading the docs!) is that in PaX we want to handle the problems posed by memory corruption bugs. all such bugs. the approach chosen in PaX is based on preventing exploit techniques from working (vs. preventing specific bug situations from occuring, at least for now, efficient full runtime bounds checking will have to wait a bit). in the docs you will find a classificaiton of exploit techniques: (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program
Re: Exec-Shield vs. PaX
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote: since a few points have been made regarding $subject, let me clear up a few of them: 1. 'It seems that exec-shield does 99% of what PaX does' this is not the case and i'm not claiming it. If you feel attacked, please dont - i'll stipulate that PaX gives better security than exec-shield, ok? i don't know the origin of that number above, for now i'll just stick to the facts i know: - PaX implements perfect non-executable pages on amd64, i386, ia64, parisc, ppc, sparc and sparc64 whereas Exec-Shield has some imitation of it only on i386 (it's not true per-page). non-executable pages on anything else but i386 is a triviality, as the hardware and the kernel supports it. There's virtually nothing that PaX or exec-shield has to add to enable them - they are there. [there's the minor issue of the process stack's protection bits.] - PaX implements best-effort randomization of the entire address space, Exec-Shield does it too but at a higher code complexity and a lower entropy rate while having a worse effect on the kernel entropy pool. lets also point out that exec-shield offers relative randomization of DSOs to each other, while PaX only randomizes a single base of the DSOs, their relative addresses remain constant. This way the randomization bits of exec-shield add up for brute-force attacks. Lets add it that if a limited exploit can be turned into an information leak then relative randomization does not help - but it does help if the first exploit itself needs precise addresses from multiple DSOs. (I agree that exec-shield drains the entropy pool more, i've got this on my TODO.) second, paxtest had some bugs which Exec-Shield exposed and made Exec-Shield appear better than it is. i've fixed them here and expect to release 0.9.5 today or so. the results now look like: ( how fair that you give me a chance to run it ... not. ) 3. MPROTECT is bogus it is not. Ingo says so because he did not understand how PaX works. [...] [ ... to 100% prevent: ] (1) introduce/execute arbitrary code (2) execute existing code out of original program order (3) execute existing code in original program order with arbitrary data no. No offense meant, but i say so because right now i dont see the way to have a generic and usable Linux system with all the restrictions you are talking about. If you complete your project and everything works and it's still the same live, flexible and kicking Linux system that we all know and love then i was clearly wrong. Right now it seems to be heading more in the direction of a prison - but this is just my judgement. In any case, i did not want to add any of that to exec-shield. I'll leave the prison guard work to selinux. you do realise that most of those 'exploit techniques' overlap with some programming concepts, and you think that those concepts are flawed by design and should be eliminated - i dont agree with this characterisation. denying executability of non-executable memory is a fair game - well specified and a clear-cut goal. Restricting an OS to do what is arguably a fair thing to do in a number of cases did not sound so clear-cut to me - end of story. You might still be right in the long run, but it wasnt obviously right at first sight, and was not complete either so it had limited value at this stage. 4. PaX breaks apps, specs, whatnot - apps that by their nature want to generate code runtime (e.g., java). they're broken for good which many people noticed by now. that's good, that was my purpose because i wanted to draw attention to the fact that runtime code generation is an important privilege that should be carefully managed (as it happens to be also one of the exploit techniques). [...] i think here we are in a fundamental disagreement. To take it to the extreme, being able to 'generate code' [ie. allow an application to write code, etc.] is one of the fundamental properties of any Linux user account, and hopefully remains so in the future. If you take that 'privilege' away you'll take away what drives Linux forward - a constantly growing pool of programmers. I dont want good security to rely on the system's insistence to remove the ability to generate code from as many codepaths as possible. There's got to be another way to secure those damn apps ... the price you are willing to pay is i believe way too high. i find your approach interesting nevertheless, and i wish you good luck in bringing it to completion. about PaX breaking specs: i urge Ingo and others saying this to point me to the precise location in SUSv3 or POSIX 1003.1-2001 that PaX conflicts with. [...] many areas of PaX conflict with one of the most basic rule of Linux: http://lwn.net/Articles/32980/ [ that i was part of that discussion is only an annoying accident, ending up in an API/ABI discussion again was unintended. ] about
Re: Exec-Shield vs. PaX
On Tue, 4 Nov 2003 [EMAIL PROTECTED] wrote:
second, paxtest had some bugs which Exec-Shield exposed and made
Exec-Shield appear better than it is. i've fixed them here and
expect to release 0.9.5 today or so. the results now look like:
i downloaded the new 0.9.5 paxtest package and amongst other changes it
has the following oneliner change:
--- paxtest-0.9.4/body.c
+++ paxtest-0.9.5/body.c
@@ -29,6 +29,7 @@
fflush( stdout );
if( fork() == 0 ) {
+ do_mprotect((unsigned long)argv ~4095U, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC);
doit();
} else {
wait( status );
this intentionally calls mprotect(PROT_EXEC) for the highest possible
address one can think of. This call has no useful purpose at all. In other
words, this is a specific, underhand cheat to trigger 'Vulnerable'
messages for all items when running paxtest on exec-shield kernels.
Bravo!
frankly, i've never experienced anything like this in my many years in the
Linux world. You so far gave the impression of a reasonable and balanced
person but this is as low as it gets. Shame on you.
here are the paxtest-0.9.5 results with that single purpose-less line
removed, for the categories that matter to me:
Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Anonymous mapping randomisation test : 8 bits (guessed)
Heap randomisation test (ET_EXEC): 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : 12 bits (guessed)
Shared library randomisation test: 12 bits (guessed)
Stack randomisation test (SEGMEXEC) : 17 bits (guessed)
Stack randomisation test (PAGEEXEC) : 17 bits (guessed)
Executable shared library bss: Vulnerable
Executable shared library data : Vulnerable
Ingo
