From: Joel Eriksson (je-dailydavebitnux.com)
Date: Tue May 04 2004 - 04:03:54 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Mon, May 03, 2004 at 12:29:21PM +0200, pageexecfreemail.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 file
> >
> > False. 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 exploit
>
> what 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
-------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]