Stack protection mechanisms range from
marking the stack as nonexecutable to inserting larger randomly sized blocks of data at
the bottom of the stack (higher memory addresses) to make return address prediction
more difficult. Return to libc exploits were developed as a means of removing reliance
on the stack for hosting shellcode. Solar Designer demonstrated return to libc style
exploits in a post to the Bugtraq mailing list (see ???References???). The basic idea behind a
return to libc exploit is to overwrite a saved return address on the stack with the address
of an interesting library function. When the exploited function returns, the overwritten
return address directs execution to the libc function rather than returning to the original
calling function. If you can return to a function such as system(), you can execute virtually
any program available on the victim system.
NOTE The system() function is a standard C library function that executes
any named program and does not return to the calling program until the
named program has completed. Launching a shell using system looks like this:
system(???/bin/sh???);
For dynamically linked executables, the system() function will be present somewhere
in memory along with every other C library function.
Pages:
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829