On 6/10/2005 15:06:44, Marco Matthies ([EMAIL PROTECTED]) 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 useful 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. -- [email protected] mailing list
