I decided to do a demonstration of SSP for a friend. It was a little embarassing, mainly because in doing so I stumbled accross an anomoly in stack smash protection. Sparing the details, I found a possible way to get around ssp and execute shellcode or ret2libc. I will present my evidence and a process for reproduction. Reproducible: Always Steps to Reproduce: 1. download vuln.c - Take note of the structure of vuln.c - Line 3 begins vuln_cpystr(), a 0 returning int function - Line 9 allocates a 10 byte static buffer a - Line 13 calls vuln_cpystr() to copy whatever is in argv[1] to a - Line 14 prints "Success." to the screen 2. Compile vuln.c with no optimization - gcc -O0 vuln.c -o vuln - optionally use -ggdb and/or -fstack-protector - use -fstack-protector if you do not have hardened-gcc enabled 3. Run vuln.c with a sufficient excess for the buffer - ./vuln.c 1234567890123456 - If this does not set off ssp, make sure you linked with ssp, and if so, supply more data Actual Results: bluefox@icebox bluefox $ gcc -O0 vuln.c -o vuln -fstack-protector -ggdb bluefox@icebox bluefox $ ./vuln 1234567890123456 Copying input buffer of length 16 to internal buffer of length 10 Success. vuln: stack smashing attack in function main() Segmentation fault bluefox@icebox bluefox $ Expected Results: bluefox@icebox bluefox $ gcc -O0 vuln.c -o vuln -fstack-protector -ggdb bluefox@icebox bluefox $ ./vuln 1234567890123456 Copying input buffer of length 16 to internal buffer of length 10 vuln: stack smashing attack in function vuln_cpystr() Segmentation fault bluefox@icebox bluefox $ Compiling with -ggdb gives the same results. This is not a case of the ssp library not knowing about anything but main. Besides that, the program manages to spit out "Success." Replacing line 9 with: char *a = malloc(10); Causes the following: bluefox@icebox bluefox $ gcc -O0 vuln.c -o vuln -fstack-protector bluefox@icebox bluefox $ ./vuln 1234567890123456028965901635021649021904665123056 Copying input buffer of length 49 to internal buffer of length 10 Success. bluefox@icebox bluefox $ This has been tested with and without the -fstack-protector in both the char a[10] and the malloc() case. It is not caught at all when using malloc(). This is extremely dangerous; dynamic buffers do not seem to be protected at all, and it appears that if I were to manage to overwrite my return value for vuln_cpystr(), I could perform a ret2libc attack. bluefox@icebox bluefox $ emerge --info Portage 2.0.50-r1 (hardened-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4-grsec) ================================================================= System uname: 2.6.4-grsec i686 Gentoo Base System version 1.4.3.13p1 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distcc fixpackages sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j25 -l11" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/xorg /usr/local/portage/spyderous /usr/local/portage/bmggnome" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3ds X aalib alsa berkdb cdr composite crypt cups dri dvd flac gif gimpprint gnome gpm gstreamer gtk gtk2 gtkhtml hardened imlib java jbig jpeg justify lcms matroska mmap mng mozilla mpeg nls nptl offensive oggvorbis openal opengl pam perl pic pie png ppds python qt quicktime readline samba sdl speex spell ssl svga tcltk theora tiff truetype videos wmf x86 xml xml2 xmms xv zlib"
Created attachment 27540 [details] vuln.c vuln.c, the almighty vuln tester!
because I updated vuln.c but didn't update the steps to reproduce, Line 13 and Line 14 in the Steps to Reproduce should be Line 17 and Line 18. Sorry.
More testing shows that declaring char a[10] in the vuln_cpstr() function and copying a large buffer to a with strcpy() WILL terminate the program. Unfortunately, using an malloc()'d 10 byte buffer, stack smash protection does nothing: with char *a = malloc(10) in vuln_cpystr(), strcpy(a,from): bluefox@icebox bluefox $ gcc -O0 vuln.c -o vuln -fstack-protector-all bluefox@icebox bluefox $ ./vuln 1234567890123456028965901635021649021904665123056 Copying input buffer of length 52 to internal buffer of length 10 Success. with char a[10] in vuln_cpystr(), strcpy(a,from): bluefox@icebox bluefox $ gcc -O0 vuln.c -o vuln -fstack-protector-all bluefox@icebox bluefox $ ./vuln 1234567890123456028965901635021649021904665123056 Copying input buffer of length 52 to internal buffer of length 10 vuln: stack smashing attack in function vuln_cpystr() Segmentation fault stack smash protection has a long way to go. We need: - Protection of passed pointers - Protection of malloc()ed buffers
Is there anything that Gentoo can do to address this bug? I think if you have something to prove about defeating ssp you should take it UPSTREAM
