On 6/10/2005 15:06:44, Marco Matthies (marco-ml@xxxxxxx) wrote:
>
Apparently, you can use repeated jumps to libc to slowly fill the
>
registers with values you need for your finall call to libc, which would
>
then run a "/bin/bash", "rm -rf /" or whatever via system() -- at least
>
that's what i understood.
This is called a 'return to libc' attack; there are plenty of good explanations
available on the net, googling for "return to libc" should pick some up.
Phrack have some easy-to-read examples (phrack.org).
Protecting the stack against execution prevents trivial exploitation of buffer
overflows that simply inject shellcode onto the stack. PaX kernels make a good
job of this, and also keep the stack NX even when gcc has generated trampolines
(little bits of code that it puts on the stack, calculated at runtime).
RedHat's ExecShield isn't quite so strict, and allows any application that uses
trampolines to have executable stack; instead RedHat remove trampolines where
they can to reduce the need for executable stack.
However the stack is where return addresses from function calls are stored;
overwriting these changes the program execution flow and can be exploited
without tripping no-execution protections on the stack. A return-to-libc
attack could be considered "harder" than a traditional trivial overflow
exploit, but the fact remains they work so whether it's more work or not to
exploit is irrelevant. They're also very useful for exploiting heap overflows,
by redirecting program flow to heap data overwritten with shellcode from a
previous heap buffer overflow. A PaX kernel makes these attacks a lot harder
by randomising the addresses at which applications, libraries and stacks are
located, and by default making heap space non-executable. Randomisation means
the attacker has to find out where libc is, without crashing the victim
process, and the NX heap means heap overflows become much less usef
ul to the attacker.
Also helping protect against return-to-libc attacks is the stack smashing
protector. This attempts to detect corruption of the stack by adding canaries
such that any stack overflow would overwrite the canary as well as the return
address; functions automatically check the canary before using the return
address on the stack and abort the process if the canary is dead. You'll see
more stuff in the linux press about it now, as RedHat have worked up a new
implementation that has been incorporated into GCC main trunk.
>
I'm no security expert -- i know the basics about how these exploits
>
work, but have never cared to get into all the hairy details, so here
>
are my questions:
>
>
Do we currently have address space layout randomization on amd64 (or
>
other archs), and will it actually help in these sort of attacks?
>
I saw a mention of adding it to the kernel in [3], has that gone through?
For ASLR (Address Space Layout Randomisation) you need a PaX-enabled kernel;
emerge hardened-sources and try it out. You need to switch on a bunch of
grsecurity stuff for it to be effective (in particular the
/proc/<pid>/[maps|stat] restrictions), and to take advantage of ASLR on
applications you need them to be built as PIEs (Position Independent
Executables). You will also need to avoid prelinking, as prelink causes all
the load addresses of shared libraries to be fixed into predictable locations
by its very nature.
>
Do we have stack-smashing protection, and can this actually help against
>
return to libc attacks? Judging from the gcc USE flags, it seems to be
>
there at least -- is it also activated automatically?
It is switched on automatically if you use the hardened compiler, as is
building PIEs, and support is built-in to glibc. You should be able to switch
to the hardened compiler using gcc-config (you probably don't need to rebuild
gcc - the only thing 'USE=hardened' does when building gcc is to change which
compiler is selected by default after installation, and the names of the
compilers).
>
I'm currently reading up on all this stuff, as well as looking at the
>
hardened profile and all the other gentoo security stuff, but if anyone
>
has a quick answer to my questions i'd be very grateful!
There are some docs on www.grsecurity.net and pax.grsecurity.net you may want
to read as well.
Kev.
--
gentoo-amd64@xxxxxxxxxx mailing list