Dailydave mailing list archives
Re: re: PaX PoC-exploit.
From: Joel Eriksson <je-dailydave () bitnux com>
Date: Tue, 4 May 2004 11:03:54 +0200
On Mon, May 03, 2004 at 12:29:21PM +0200, pageexec () freemail hu wrote:
Enforce a minimum delay before a SIGSEGV:ed program can be executed again (and before a parent process with a SIGSEGV:ed child can fork() again).how's that different from e.g., RES_CRASH 1 1s?
It's not, but that's a grsec feature, which is only available when using ACLs. Since there are some other projects that uses PaX I think it would be useful to integrate that functionality to the main PaX patch. Further down in your reply you say that it could break other stuff since it's not a standard resource and userspace tools would have to be modified to make of it, but why not just add a compile time option that enables this feature and lets the user choose a fixed minimum delay?
Btw, in case spender reads this, a feature I would like to see in grsecurity would be to enforce fd 0, 1 and 2 being open upon execution of SUID/SGID programs, as with OpenWall that opens /dev/null on those descriptors in case they are closed. The kind of bugs possible without that feature can be pretty sneaky.grsec had this till 1.9.4-2.4.18, but i don't know anymore why it was removed.
Spender explained this one to me. :) Glibc does this nowadays so it doesn't need a kernelspace workaround anymore. I still think it would be useful to enforce this in the kernel since not all Linux-systems are based on glibc (embedded systems often use smaller alternatives, like uClibc or newlib) but I guess one could just rip that part of the openwall-patch for those systems.
what are these conditions? 1. ability to create an (executable) file 2. ability to execute the above created (or arbitrary) executable fileFalse. Interpreters like Perl, Python or any other of the powerful script languages could be used to make a similar exploit too (even bash alone could be used actually).i think we have a definition crisis of some sort here ;-). the PaX/grsec guarantee i was talking about is for introducing/executing new *machine* code, what you are describing is not that (albeit similar in effect), it's introducing new data that drives already existing code. it's of course a valid security hazard but there's about nothing one can do about it (halting problem and the like comes to mind). i still stand by my claim that you cannot execute your own (machine) code (under the circumstances i specified, PaX/grsec/ACLs).
True, but as I pointed out in my previous mail I could just as well have executed something else by either using a symlink or by using the offset to /bin/sh in glibc instead of the static string in the ELF-header. Thus, the conditions you listed above are _not_ necessary for this PoC. :) Executing /bin/sh would be useless for locals since it resets the EUID, but with a symlink I could have executed perl instead, that doesn't do any EUID-resetting but that lets me set UID = EUID with: $< = $>; and then execute /bin/sh. ACLs would be able to prevent this, yes, unless the program that is exploited needs to be able to execute the program I want to execute under normal operations.
Not to mention that some of the systems that disallow execution of user provided files can be circumvented by executing them indirectly e via the dynamic linker, bugs in "allowed programs", etc or by simply using an interpreter instead.not sure what 'some of the systems' refer to, if you meant grsecurity based ones, then it's not possible, as i mentioned it previously, the executable feature (as defined by the ACLs) is enforced at the kernel's internal mmap() level, it doesn't matter who does the mmap() (kernel or someone in userland), a non-executable file cannot be mapped with PROT_EXEC. if you meant the circumvention of a noexec mount, then it's not possible either, mainline linux kernels (already in 2.4 and 2.6 and soon in 2.2 as well) prevent it in the trivial case, and PaX prevents it for good (reminds me, someone should write a PoC for that and post it to lkml ;-).
With "some of the systems" I was referring to simple measures like mounting noexec, glad to hear the mainline kernels takes care of this nowadays. :)
The PoC does not directly introduce/execute arbitrary code though, it executes code that already exists in the address space of the process but in an unintended manner. It simply alters the execution flow.it does rely on the ability to create/execute new machine code (a new file that can be executed). the PaX (or better, grsec) guarantee is not only for doing this directly in memory but in general and you didn't prove that wrong.
As I've previously pointed out, it doesn't. :) The sample exploit did compile the file to be executed, but that was mainly to make it print the time when the exploit succeeded. :) I was not trying to point out a flaw in PaX though, except perhaps hinting at the need for better protection against return-into-lib(c)/.text type of attacks, so no need to go defensive. ;) As far as I can tell PaX does a great job at making the use of attacker-provided shellcode impossible.
of course it's perfectly fine to exploit a weakened deployment but then please say so, otherwise the casual reader will misunderstand your conclusions.Actually, it's the other way around. My exploit works in the kind of deployment that is pretty standard and you tell me that the exploitwhat you didn't do is mention this 'tiny detail' in your PoC and just made a sweeping conclusion (blaming the security measures instead of the way it's deployed by some), that's the only part that bothered me.
You do have a point. I'll add some comments about that ACLs could and should be used to minimize the risks and consequences from this kind of attacks.
Actually, many exploit coders that I have shown the exploit for during the last few months have been rather surprised to see that such an exploit was still possible with PaX. Since the technique is well known most people seem to have assumed that PaX had some kind of protection against it by now.'many exploit coders' need to RTFM ;-).
True. ;)
Some people I talked with had assumed more entropy was involved and some thought libraries were mapped on addresses with NUL-bytes (which is not a fool-proof protection either of course, but it helps). Some people just hadn't thought further than "PaX protects against overflows, period".from http://marc.theaimsgroup.com/?l=bugtraq&m=106089684213186&w=2 (that'd be from 9 months ago) you can get http://mapage.noos.fr/hrchallenge/bpax.tgz . that's something i consider a novel (and gargantuan ;-) PoC.
Ah, very clever technique. :) But, did I miss something or wouldn't that exploit fail with a randomized ET_EXEC base? -- Best Regards, Joel Eriksson ------------------------------------------------- Cellphone: +46-70 228 64 16 Home: +46-26-10 23 37 Security Research & Systems Development at Bitnux PGP Key Server pgp.mit.edu, PGP Key ID 0x529FDBD1 A615 A1E1 3CA2 D7C2 CFEA 47B4 7EF7 E6B2 529F DBD1 ------------------------------------------------- _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://www.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- PaX PoC-exploit. Joel Eriksson (May 02)
- Re: PaX PoC-exploit. Evgeny Demidov (May 02)
- Re: PaX PoC-exploit. Joel Eriksson (May 02)
- <Possible follow-ups>
- re: PaX PoC-exploit. pageexec (May 02)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 02)
- Re: re: PaX PoC-exploit. pageexec (May 03)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 04)
- Message not available
- Re: re: PaX PoC-exploit. pageexec (May 04)
- Re: re: PaX PoC-exploit. Sinan Eren (May 06)
- Re: re: PaX PoC-exploit. Nahual (May 06)
- Re: re: PaX PoC-exploit. Nenad Stojanovski (May 06)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 06)
- Re: re: PaX PoC-exploit. ned (May 06)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 07)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 02)
- Re: re: PaX PoC-exploit. Sinan Eren (May 07)
- Re: re: PaX PoC-exploit. Joel Eriksson (May 07)
- Re: PaX PoC-exploit. Evgeny Demidov (May 02)