after recompiling gcc and related packages to include hardened (ie, ` emerge -v gcc && emerge -v binutils gcc glibc && emerge -v binutils gcc`), and then recompiling the entire system (ie, `emerge -Dev world`), samba core dumps. i get the following in dmesg: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by /usr/sbin/smbd[smbd:32203] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/smbd[smbd:32190] uid/euid:0/0 gid/egid:0/0 and the following in /var/log/samba/log.smbd: [2004/09/13 17:14:07, 0] smbd/server.c:main(760) smbd version 3.0.7 started. Copyright Andrew Tridgell and the Samba Team 1992-2004 smbd: stack smashing attack in function open_sockets_smbd() Reproducible: Always Steps to Reproduce: 1. 2. 3. # emerge info Portage 2.0.51_pre23 (default-x86-2004.2, gcc-3.4.1, glibc-2.3.4.20040619-r1, 2.6.7-hardened-r7 i686) ================================================================= System uname: 2.6.7-hardened-r7 i686 Intel(R) Xeon(TM) CPU 2.80GHz Gentoo Base System version 1.5.3 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.7-r4 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 apm avi berkdb bitmap-fonts crypt cups encode foomaticdb gdbm gif gpm gtk2 hardened imlib jpeg kerberos ldap libg++ libwww mad mikmod motif mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl pic png postgres python quicktime readline samba sdl slang snmp spell ssl svga tcpd truetype x86 xml xml2 xmms xprint xv zlib"
i should add that this prevents me from being able to connect to the samba service via a windows computer or active directory setup.
ssp is cool like that :) Somebody want to attached the file that contains the function for open_sockets_smbd() so we can see if this overflow is easily resolvable.
Created attachment 39685 [details] samba-3.0.7: ./source/smbd/server.c seems like a compiler issue, as per bug #62109 Anyway: this is the file incriminated ;-)
can you try with lower CFLAGS to resolve this as a possible false positive? in the meantime i will look at the source code of the file. thanks, Alex
Samba ebuild force 'easy' compiler settings, because we had some issue in strong optimizations: see comment 11 on bug 62109 on cflags: http://bugs.gentoo.org/show_bug.cgi?id=62109#c11
gcc version 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) 14:49:32 [/space/chroots/chroot002:8240.pts-3.papillon]papillon /etc # file $(which smbd) /usr/sbin/smbd: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped 14:49:35 [/space/chroots/chroot002:8240.pts-3.papillon]papillon /etc # emerge -pv samba These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-fs/samba-3.0.6-r2 -acl -cups -debug -doc -kerberos -ldap -mysql -oav +pam -postgres +python +readline -xml -xml2 0 kB 14:49:39 [/space/chroots/chroot002:8240.pts-3.papillon]papillon /etc # emerge info Portage 2.0.50-r10 (hardened-x86-2004.0, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.4.27-IBMA31) ================================================================= System uname: 2.4.27-IBMA31 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" 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/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="berkdb crypt hardened nls pam perl pic pie python readline ssl static tcpd x86 zlib" i could not reproduce this error with the following test setup: # /usr/sbin/nmbd -F -S --debuglevel=10 # /usr/sbin/smbd -i -F -S i was using a simple [public] dir for testing: [public] path = /tmp public = yes writable = yes printable = no Could you provide me with an URL of a quickpkg you created with a faulty smb packge? TIA, Alex
http://www.final-frontier.org/samba-3.0.7-r1.tbz2 , compiled on the following system: earthdawn ~ # emerge info Portage 2.0.51_rc4 (hardened/x86, gcc-3.4.2, glibc-2.3.3.20040420-r1, 2.6.7-hardened-r8 i686) ================================================================= System uname: 2.6.7-hardened-r8 i686 AMD Duron(tm) Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/storage/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ ftp://gentoo.inode.at/source/ http://gentoo.inode.at" MAKEOPTS="-j2" PKGDIR="/storage/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://localhost/gentoo-portage" USE="3dnow acpi apache2 apm bcmath berkdb bzlib calendar chroot cpdflib crypt ctype curl curlwrappers dba erandom exif exim exisc an-acl fam flatfile ftp gd gdbm gif gmp gpm hardened hardenedphp iconv imagemagick imap inifile innodb ithreads java jpeg ldap ma ildir mhash mime mmx mysql nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses nls nptl pam parse-clocks pcntl pcre pdflib perl pic pie png posix python readline samba sasl session sharedmem simplexml slang snmp sockets socks5 spell spl sse ssl sysvipc tcpd threads tidy tiff tokenizer truetype usb vhosts wddx wildlsearch x86 xml xml2 xmlrpc xsl zlib" The core dumps do not occur if samba is compiled with gcc <= 3.3.x Hope this quickpkg helps.
thanks much for the .tgz, i will try with a recent 3.4 gcc :-)
while testing with your package, this error occurred, which is LDAP related: /usr/sbin/smbd: error while loading shared libraries: libldap.so.2: cannot open shared object file: No such file or directory can you give me all of your packages (look at the USE flags) in the meantime, this is my testing playground here: Portage 2.0.51_rc6 (hardened/x86, gcc-3.4.2, glibc-2.3.3.20040420-r1, 2.4.27 i686) ================================================================= System uname: 2.4.27 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.4.3-r4 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="" CHOST="i686-pc-linux-gnu" COMPILER="" 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/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/portage-overlay" SYNC="rsync://spout.ussg.indiana.edu/gentoo-portage" USE="berkdb crypt hardened nls pam perl pic pie python readline ssl static tcpd x86 zlib" gcc version 3.4.2 (Gentoo Hardened Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5) [ebuild R ] sys-libs/glibc-2.3.3.20040420-r1 -build -debug* -erandom +hardened +nls -nptl +pic 0 kB [1] # /usr/sbin/nmbd -F works # /usr/sbin/smbd -F works too i was using the simple command "smbclient -L 127.0.0.1" for testing do you need something more complicated for me to do to reproduce the error? so far compiling it PIE SSP did not show any oddities... bye, Alex
update: smbmounting //127.0.0.1/tmp (as in the smb.conf) to /mnt/temp2 and copying huge loads of data seems to work too. Now i would like to look at your ldap stuff with you, ok? TIA, Alex
my binaries can be found here: http://www.brundagemgt.com/gentoo/mit-krb5-1.3.4.tbz2 http://www.brundagemgt.com/gentoo/openldap-2.1.30-r3.tbz2 http://www.brundagemgt.com/gentoo/samba-3.0.7.tbz2 on affected box: # smbclient -L 127.0.0.1 protocol negotiation failed and corresponding entry in /var/log/samba/log.smbd: [2004/09/28 10:41:11, 0] smbd/server.c:main(760) smbd version 3.0.7 started. Copyright Andrew Tridgell and the Samba Team 1992-2004 smbd: stack smashing attack in function open_sockets_smbd()
thanks much, will look at it immediately :-)
Here are my packages: http://www.final-frontier.org/openldap-2.1.30-r3.tbz2 http://www.final-frontier.org/mysql-4.0.20-r1.tbz2 http://www.final-frontier.org/libxml2-2.6.12.tbz2 Maybe there are more that are now missing...
Fri Oct 1 03:24:37 CEST 2004 could reproduce the error and caught the offending function with a "smoking gun" stack snapshot: root 20244 85.9 0.3 8396 2460 pts/14 R 03:32 1:49 | \_ /usr/sbin/smbd -F -S root 20245 0.0 0.3 8396 2484 pts/14 S 03:32 0:00 | \_ /usr/sbin/smbd -F -S root 20300 3.3 0.3 8396 2448 pts/14 T 03:32 0:03 | \_ /usr/sbin/smbd -F -S # gdb attach 20300 ... shared libraries rolling in ... .FREEZER () at ssp.c:6 6 void __stack_smash_handler (char func[], int damaged) { asm(".FREEZER: jmp .FREEZER"); } (gdb) where #0 .FREEZER () at ssp.c:6 #1 0x08290666 in open_sockets_smbd (is_daemon=0, interactive=0, smb_ports=0x11 <Address 0x11 out of bounds>) at smbd/server.c:459 #2 0x00000000 in ?? () (gdb) info frame Stack level 0, frame at 0xbfffe140: eip = 0x4001657b in __stack_smash_handler (ssp.c:6); saved eip 0x8290666 called by frame at 0xbffff340 source language c. Arglist at 0xbfffe138, args: func=0x8396d28 "open_sockets_smbd", damaged=0 Locals at 0xbfffe138, Previous frame's sp is 0xbfffe140 Saved registers: ebp at 0xbfffe138, eip at 0xbfffe13c (gdb) x/260x $esp 0xbfffe138: 0xbffff338 0x08290666 0x08396d28 0x00000000 this is the saved EIP of the command following the calling function: (gdb) x/i 0x08290666 0x8290666 <open_sockets_smbd+2697>: add $0x11ec,%esp (gdb) x/i open_sockets_smbd+2692 0x8290661 <open_sockets_smbd+2692>: call 0x80820c0 <strcmp+4112> (gdb) x/i 0x80820c0 0x80820c0 <strcmp+4112>: jmp *0x83ac4b8 (gdb) x/i *0x83ac4b8 0x40016578 <__stack_smash_handler>: push %ebp here is the value for the saved EIP for reference again: 0x8290666 <open_sockets_smbd+2697>: add $0x11ec,%esp this is the first argument: (gdb) x/s 0x08396d28 <__FUNCTION__.20+2246>: "open_sockets_smbd" This is what should be "left over" from the defunct stack frame of the open_sockets_smbd function: 0xbfffe148: 0xbfffe184 0x00000000 0x00000000 0x00000000 0xbfffe158: 0x00000000 0x00000000 0x40137421 0x00000000 0xbfffe168: 0x00000001 0x40100be1 0xbfffe200 0x00000002 0xbfffe178: 0x00000011 0x00000002 0x00000000 0x00000010 0xbfffe188: 0x084a7947 0x00000000 0x00000000 0x00000000 0xbfffe198: 0x00000000 0x00000000 0x0831477c 0x00000001 0xbfffe1a8: 0x00000005 0x19999999 0x00000000 0x401e7fe0 0xbfffe1b8: 0x0831477c 0x400fe59e 0xbfffe1e0 0x40100608 0xbfffe1c8: 0x0831477c 0xbfffe210 0x40137421 0x00000000 0xbfffe1d8: 0x401e8500 0x401e7fe0 0xbfffe224 0x00000001 0xbfffe1e8: 0xbfffe2d0 0x401e99fc 0x401e99a0 0x00000030 0xbfffe1f8: 0x401e99a0 0x401e99a0 0x00000011 0x00000012 0xbfffe208: 0x401e99fc 0x00206e65 0x0831477d 0x0000007f 0xbfffe218: 0x08314774 0x08314775 0x0833d552 0xbfffe238 0xbfffe228: 0x40199a68 0x400fe777 0xdeadbeef 0x0100007f there is our dead beef "chicken" again :-) 0xbfffe238: 0x401e99a0 0x0820bf99 0x08498d60 0x00000004 0xbfffe248: 0x00000020 0x401e7fe0 0x401e99a0 0x401e99a0 0xbfffe258: 0xbfffe278 0x40138d31 0x401e99a0 0x00000018 0xbfffe268: 0x00000018 0xbfffe2d0 0x00000018 0x40014d00 0xbfffe278: 0xbfffe2a8 0x0820e78b 0x08498d68 0xbfffe2d0 0xbfffe288: 0x00000018 0x08317504 0xdeadbeef 0x40383307 0xbfffe298: 0x083ed0b8 0xbfffe2d0 0xbfffe2d0 0x00000000 0xbfffe2a8: 0xbfffeef8 0x081f69e0 0xbfffe2d0 0x00000018 0xbfffe2b8: 0xbfffe43c 0x00000003 0x083ed388 0x00000000 0xbfffe2c8: 0x043e4d73 0x40383307 0x00006f6c 0x00000000 0xbfffe2d8: 0x40126cd4 0x00000000 0x0100007f 0x000000ff 0xbfffe2e8: 0x00000000 0x0836bcf2 0x00000004 0xbfffe904 0xbfffe2f8: 0x4010fa29 0xbfffe930 0x0836bcf2 0x00000004 0xbfffe308: 0x00000000 0x083910b3 0x00000000 0xbfffe924 0xbfffe318: 0x4010fa29 0xbfffe94c 0x083910b3 0x40110abe 0xbfffe328: 0xbfffe8e0 0xbfffe4b0 0x4000bb61 0x40383373 0xbfffe338: 0x400e3ec1 0x401e99a0 0x043e4d73 0x40110abe 0xbfffe348: 0xbfffe900 0xbfffe4d0 0x00000020 0x00000020 0xbfffe358: 0x00000004 0x00000004 0x00000000 0x00000000 0xbfffe368: 0x00000000 0x40137421 0x20733373 0x00000000 0xbfffe378: 0xffffffff 0xfffffff7 0x00000000 0x00000000 0xbfffe388: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe398: 0x00000000 0x00000000 0x40137421 0x00001000 0xbfffe3a8: 0x00000001 0x40014ff0 0x083ed110 0x00000000 0xbfffe3b8: 0x00000054 0x00000002 0xbfffe9f8 0xbfffe86c 0xbfffe3c8: 0x00000000 0x083174ff 0x00000018 0xffffffff 0xbfffe3d8: 0x00000000 0x00000000 0xbfffe480 0x20730058 0xbfffe3e8: 0x00000000 0xffffffff 0xfffffffc 0x00000000 0xbfffe3f8: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe408: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe418: 0x00000000 0x00000000 0x00000000 0x00000000 0xbfffe428: 0x00000000 0x00000001 0x00000002 0xbfffea5c 0xbfffe438: 0xbfffe8e0 0x00000000 0x0836bced 0x00000017 0xbfffe448: 0xffffffff 0x00000000 0x00000001 0xbfffeea4 0xbfffe458: 0xbfffe900 0x00000000 0x083910b1 0x00000033 0xbfffe468: 0xffffffff 0x00000000 0x40137421 0x00000025 0xbfffe478: 0x00000000 0x00000000 0x00000000 0x083eb880 0xbfffe488: 0x40014ff0 0x00000000 0x401e99a0 0x00000020 0xbfffe498: 0x401e99a0 0x401e99a0 0x401e9da0 0x00000048 0xbfffe4a8: 0x0836bcf6 0x400dec9c 0x00000000 0x00000000 0xbfffe4b8: 0x40015470 0x00000000 0xbffff524 0x00000003 0xbfffe4c8: 0x083910b3 0x40014d00 0x00000000 0x00000000 0xbfffe4d8: 0xbfffe618 0x081f5b2d 0x08498d30 0x00000003 0xbfffe4e8: 0x00000010 0x401e7fe0 0x401e99a0 0x401e99a0 0xbfffe4f8: 0xbfffe518 0x40138d31 0x401e99a0 0x0000000c 0xbfffe508: 0x40133f54 0x00000002 0x083eba58 0x00000007 0xbfffe518: 0xbfffe558 0x08212af1 0x0000000c 0xbfffe570 0xbfffe528: 0xdeadbeef 0xbfffea9e 0x40137421 0x00000003 0xbfffe538: 0x00000001 0x083ed110 0x00000001 0x083ed0b8 lets look at the stack frames again: (gdb) info frame Stack level 0, frame at 0xbfffe140: eip = 0x4001657b in __stack_smash_handler (ssp.c:6); saved eip 0x8290666 called by frame at 0xbffff340 source language c. Arglist at 0xbfffe138, args: func=0x8396d28 "open_sockets_smbd", damaged=0 Locals at 0xbfffe138, Previous frame's sp is 0xbfffe140 Saved registers: ebp at 0xbfffe138, eip at 0xbfffe13c (gdb) info frame 1 Stack frame at 0xbffff340: eip = 0x8290666 in open_sockets_smbd (smbd/server.c:459); saved eip 0x0 called by frame at 0x0, caller of frame at 0xbfffe140 source language c. Arglist at 0xbffff338, args: is_daemon=0, interactive=0, smb_ports=0x11 <Address 0x11 out of bounds> Locals at 0xbffff338, Previous frame's sp is 0xbffff340 Saved registers: ebx at 0xbffff32c, ebp at 0xbffff338, esi at 0xbffff330, edi at 0xbffff334, eip at 0xbffff33c (gdb) info frame 2 Stack frame at 0x0: eip = 0x0; saved eip 0x0 caller of frame at 0xbffff340 Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0xbffff340 Saved registers: ebx at 0xbffff32c, ebp at 0xbffff338, esi at 0xbffff330, edi at 0xbffff334, eip at 0xbffff33c And now to something completely different: Given that the saved frame pointer and the saved instruction pointer (the artist formerly known as return address) are zeroed out, we can assume that the function in fact does smash the stack upwards, only a little bit. It seems that there are emitted zeroes on the stack that destroy the critical layout, however, i am too stupid to find out where they come from by just having this "barebone" stack frame zipped by gdb. Next big thing: compiling the whole story with libmudflap and trying to catch the error with "pants down". An interesting side note: i was using this trick to catch SSP "in the act": # cat ssp.c /* $Header: /var/cvsroot/gentoo-x86/sys-libs/glibc/files/2.3.3/ssp.c,v 1.3 2004/08/07 17:53:20 solar Exp $ */ #include <stdio.h> unsigned long __guard = 0UL; void __stack_smash_handler (char func[], int damaged) { asm(".FREEZER: jmp .FREEZER"); } void __guard_setup (void) { __guard = 0xdeadbeef; } # cat Makefile all: # ulimit -c unlimited gcc -g -ggdb -fPIC -fno-stack-protector -fno-stack-protector-all -c -o ssp.o ssp.c gcc -g -ggdb -fPIC -fno-stack-protector -fno-stack-protector-all -shared -o libssp.so ssp.o 392 clear; LD_PRELOAD="/root/libssp/libssp.so" /usr/sbin/smbd -F -S This enables us to "hook" our gdb session up to the "frozen" process in the __stack_smash_handler function- good for forking processes when their childs die at early age. Thanks for your help so far, Alex
Sat Oct 2 13:59:28 CEST 2004 War ja klar, der Fehler ist nicht zu reproduzieren mit dem gcc-3.4.2-HTB-1.00 (W
Sat Oct 2 13:59:28 CEST 2004 War ja klar, der Fehler ist nicht zu reproduzieren mit dem gcc-3.4.2-HTB-1.00 (Wäre ja auch zu schön gewesen) Sat Oct 2 16:54:23 CEST 2004 testing with gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, HTB-1.00) showed no error: # /usr/sbin/smbd -F -S smbd version 3.0.7 started. Copyright Andrew Tridgell and the Samba Team 1992-2004 Unable to open printcap file lpstat for read! standard input is not a socket, assuming -D option [0] pappy@PAPILLON pappy $ smbclient -L 127.0.0.1 Password: Domain=[PAPILLON] OS=[Unix] Server=[Samba 3.0.7] The results of this test are questionable: 1) there is a security problem 1a) the SSP patch finds it, the bounds checking patch does not. 2) there is no security problem 2a) the SSP patch provoked the error and the bounds checking patch right about not finding anything. I think the solution to this problem can only be found in the "scenario" when samba was compiled with SSP.
forget the last comment, its nonsense, forgot to add the bounds checking transparently to the specs!
Well pappy called me from Germany on his cellphone to tell me he tracked down exactly why this is happening. It's a plain and simple broken/unsafe MACRO() within samba which overwrites the part of the stackframe of the calling function. This bug exists for everybody but only the hardened toolchain was . It's unknown still if it's exploitable to gain anything fun. But I assume he will keep working at it with our samba/security teams or upstream till a patch which corrects this behavior exists.
No matter how many times you read what you wrote you never catch your mistakes till you hit [Commit] -This bug exists for everybody but only the hardened toolchain was . +This bug exists for everybody but only the hardened toolchain was exposing the underlying problem.
The following asm macro in open_sockets_smbd() is responsible for the stack smashing which destroys the __guard in the open_sockets_smbd() and the main() stack frame: from samba-3.0.7/work/samba-3.0.7/source/smbd/server.c // this macro destroys the __guard and the stack frame of main() and its mother function // which is open_sockets_smbd() // the SSP epilogue in open_sockets_smbd() will trigger an alert // however, what made it so hard to find was that the functions down all work :-((( // only when the child was about to exit the function, it bites back because of the destroyed stack frames FD_ZERO(&listen_set); The full asm macro (with gcc -E) do { int __d0, __d1; __asm__ __volatile__ ("cld; rep; stosl" : "=c" (__d0), "=D" (__d1) : "a" (0), "0" (sizeof (fd_set) / sizeof (__fd_mask)), " 1" (&((&listen_set)->fds_bits)[0]) : "memory"); } while (0); this is from gcc -S .LBE4: .loc 1 208 0 call CatchChild .LBB5: .loc 1 214 0 movl $0, %eax movl $32, %ecx leal -72(%ebp), %edi #APP cld; rep; stosl #NO_APP .LBE5: .loc 1 220 0 testl %ebx, %ebx ds ; jne .L41 .loc 1 221 0 call lp_smb_ports .loc 1 223 0 testl %eax, %eax je .L43 cmpb $0, (%eax) jne .L42 .L43: Next i will display a gdb session
The macro is from GLIBC, thanks to Peter Busser for helping me out (man FD_ZERO also helps you) 12:07:27 <pappy-> /usr/include/bits/select.h:# define __FD_ZERO(set) \ 12:07:27 <pappy-> /usr/include/sys/select.h:#define FD_ZERO(fdsetp) __FD_ZERO (fdsetp) #if defined __GNUC__ && __GNUC__ >= 2 # define __FD_ZERO(fdsp) \ do { \ int __d0, __d1; \ __asm__ __volatile__ ("cld; rep; stosl" \ : "=c" (__d0), "=D" (__d1) \ : "a" (0), "0" (sizeof (fd_set) \ / sizeof (__fd_mask)), \ "1" (&__FDS_BITS (fdsp)[0]) \ : "memory"); \ } while (0) # define __FD_SET(fd, fdsp) \ __asm__ __volatile__ ("btsl %1,%0" \ : "=m" (__FDS_BITS (fdsp)[__FDELT (fd)]) \ : "r" (((int) (fd)) % __NFDBITS) \ : "cc","memory") # define __FD_CLR(fd, fdsp) \ __asm__ __volatile__ ("btrl %1,%0" \ : "=m" (__FDS_BITS (fdsp)[__FDELT (fd)]) \ : "r" (((int) (fd)) % __NFDBITS) \ : "cc","memory") # define __FD_ISSET(fd, fdsp) \ (__extension__ \ ({register char __result; \ __asm__ __volatile__ ("btl %1,%2 ; setcb %b0" \ : "=q" (__result) \ : "r" (((int) (fd)) % __NFDBITS), \ "m" (__FDS_BITS (fdsp)[__FDELT (fd)]) \ : "cc"); \ __result; })) #else /* ! GNU CC */ /* We don't use `memset' because this would require a prototype and the array isn't too big. */ # define __FD_ZERO(set) \ do { \ unsigned int __i; \ fd_set *__arr = (set); \ for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \ __FDS_BITS (__arr)[__i] = 0; \ } while (0) # define __FD_SET(d, set) (__FDS_BITS (set)[__FDELT (d)] |= __FDMASK (d)) # define __FD_CLR(d, set) (__FDS_BITS (set)[__FDELT (d)] &= ~__FDMASK (d)) # define __FD_ISSET(d, set) (__FDS_BITS (set)[__FDELT (d)] & __FDMASK (d)) #endif /* GNU CC */ This is from the glibc.
This is the FD_ZERO macro when compiled without SSP: FD_ZERO(&listen_set); 383: b8 00 00 00 00 mov $0x0,%eax 388: b9 20 00 00 00 mov $0x20,%ecx 38d: 8d bd 68 ef ff ff lea 0xffffef68(%ebp),%edi 393: fc cld 394: f3 ab repz stos %eax,%es:(%edi) This is the same FD_ZERO macro when compiled with SSP (using gcc-3.4.2-r2): FD_ZERO(&listen_set); 50b: b8 00 00 00 00 mov $0x0,%eax 510: b9 20 00 00 00 mov $0x20,%ecx 515: 8d 7d b8 lea 0xffffffb8(%ebp),%edi 518: fc cld 519: f3 ab repz stos %eax,%es:(%edi) As you can see, the SSP instrumentation of functions (which changes the location of local arrays and variables plus reserves room for a stack guard at compile time) has to modify the lea instruction because at the moment of stack modification, the SSP RTL patch in the gcc compiler is the only responsible source of information for the "new" layout. However, as pipacs found out, the SSP patch does something wrong when "modifying" the lea instruction in the FD_ZERO macro. Next thing i am going to try is with an older hardened gcc version. TIA, Alex
12:27:45 <pipacs> pappy, 128 = 0x80, lea 0xffffffb8(%ebp) -> it's less than 0x80 below the frame, so no wonder this overflows, by 0x38 bytes to be exact 12:28:24 <pipacs> if i have to point at a culprit, it'd be ssp 12:29:02 <pipacs> no, this whole is just wrong 12:29:09 <pipacs> that's why i asked you for a non-ssp disasm 12:29:40 <pipacs> 0xffffffb8 should be 0xffffff80 or even less to be able to fit 0x80 bytes 12:29:56 <pipacs> pappy, it's enough to recompile just that one .c file w/o ssp 12:30:02 <pipacs> and paste the disasm from objdump -d 12:31:11 <pipacs> see, now that looks much better 12:31:27 <pipacs> you can stop it ;) 12:31:42 <pipacs> doesn't matter, fd_set size is the same 0x20*4 12:32:01 <pipacs> and 0xffffef68 looks reasonably big space, probably lots of other buffers are after it 12:32:06 <pipacs> so, i'd say it's an ssp bug 12:32:10 <pipacs> better tell etoh 12:32:42 <pipacs> maybe you can try to reduce the code to be a few lines and still show the bug 12:32:48 <pipacs> that would be easiest for him to debug 12:33:14 <pipacs> yes 12:33:32 <pipacs> well, dunno which version of it, but the one you used definitely generates bad code 12:33:44 <pipacs> potential security risk :P 12:35:33 <pipacs> you can try to compile that .c w/ another gcc/ssp to see if the disasm becomes any better 12:36:13 <pipacs> but even if it does, it'd require a full disasm examination to see if ssp didn't accidentally overlay the fd_set with another local variable 12:36:18 <pipacs> for now you got sort of lucky in fact 12:36:41 <pipacs> since the fd_set array was overlaid with the guard itself, so it got caught, in other cases it might silent corruption 12:37:59 <pipacs> hmm? 12:38:35 <pipacs> it computes an 'effective address' (load effective address = lea) 12:38:48 <pipacs> it adds 0xffffffb8 to the value of ebp and stores it in edi 12:38:58 <pipacs> edi is the implicit destination of 'stos' 12:39:11 <pipacs> store string 12:39:20 <pipacs> 'repz' makes it repeat it 'ecx' times 12:39:37 <pipacs> tha stos is actually a stosl, ie. it stores 4 bytes at a time 12:39:43 <pipacs> so 0x20*4=0x80 12:39:52 <pipacs> no, ecx is positive 12:40:00 <pipacs> and repz decrements it 12:40:02 <pipacs> until it's 0 12:40:13 <pipacs> well, ssp reorganizes the local variables 12:40:19 <pipacs> puts arrays to the 'top' 12:40:26 <pipacs> closer to the prologue 12:40:30 <pipacs> and other variabels at the bottom 12:40:44 <pipacs> but for some reason ssp doesn't reserve enough space for fd_set 12:40:51 <pipacs> yup 12:41:03 <pipacs> there're a few arrays in this function 12:41:14 <pipacs> so ssp could have fucked up the size calculation in any one of them 12:41:18 <pipacs> doesn't have to be fd_set 12:41:23 <pipacs> could be some below it 12:41:57 <pipacs> can you try it with another ssp/gcc? 12:42:02 <pipacs> like 3.3 or older 12:42:17 <pipacs> just to know if it's a bug in the 3.4 port 12:42:27 <pipacs> Sturzflut, sure it does, but it's not buggy itself 12:42:35 <pappy-> pipacs: people say that it only happens with gcc > 3.3 12:42:38 <pipacs> (well, not in this case ;) 12:42:42 <pappy-> pipacs: as the bug states 12:42:51 <pappy-> pipacs: and i also only could reproduce it with 3.4.2 12:42:53 <pipacs> pappy, ok, i just wanted to verify that on the disasm 12:43:02 <pappy-> pipacs: i want to verify that on the disasm too 12:43:07 <pappy-> pipacs: and you just taught me what to look at 12:43:11 <pipacs> also, as i said, with a different layout ssp could be overwriting something else 12:43:17 <pipacs> which could go undetected 12:51:18 <pappy-> pipacs: i updated the bug, feel free to comment on the "real deal" in terms of technical explanation, thanks in advance. 12:51:29 <pappy-> pipacs: next thing i do is try with gcc older than 3.4.2 12:51:57 <pipacs> what's the bug id? 12:55:01 <pipacs> pappy, it's an ok explanation 12:55:06 <pipacs> nothing really to add 12:56:11 <pipacs> maybe you want to point out why ff...fb8 is not enough to hold 0x20*4 data, but that's just a detail 12:57:24 <pipacs> oh boy 12:57:32 <pipacs> i'm shy ;) 12:57:33 <pipacs> you do it
Mail to Etoh and Hardened ML: Dear Mr. Etoh, dear Mr. Yoda. The PaX team and i were able to "track down" the error with the samba-3.0.7 in correlation to gcc-3.4.2-r2: (gdb) where #0 open_sockets_smbd (is_daemon=1, interactive=0, smb_ports=0x0) at smbd/server.c:216 #1 0x0829130f in main (argc=-559038737, argv=0xbffff524) at smbd/server.c:870 (gdb) x/i $eip 0x828fc3f <open_sockets_smbd+98>: mov $0x0,%eax (gdb) 0x828fc44 <open_sockets_smbd+103>: mov $0x20,%ecx (gdb) 0x828fc49 <open_sockets_smbd+108>: lea 0xffffffb8(%ebp),%edi (gdb) 0x828fc4c <open_sockets_smbd+111>: cld (gdb) 0x828fc4d <open_sockets_smbd+112>: repz stos %eax,%es:(%edi) (gdb) 0x828fc4f <open_sockets_smbd+114>: test %ebx,%ebx (gdb) info reg $eip eip 0x828fc3f 0x828fc3f (gdb) info reg $ebp ebp 0xbffff338 0xbffff338 The "lea" instruction loads the address of %ebp into %edi, adding a negative offset (i.e.: making room) for the storing of the string by the stos (which is a stosl, store string long, 4 bytes). This offset is too small. The instrumentation of SSP changes this offset, here is the value without SSP (from the bug): This is the FD_ZERO macro when compiled without SSP: FD_ZERO(&listen_set); 383: b8 00 00 00 00 mov $0x0,%eax 388: b9 20 00 00 00 mov $0x20,%ecx 38d: 8d bd 68 ef ff ff lea 0xffffef68(%ebp),%edi 393: fc cld 394: f3 ab repz stos %eax,%es:(%edi) And this is with SSP compiled with gcc-3.3.3-r6: 4b1a3: 8b 83 a0 08 00 00 mov 0x8a0(%ebx),%eax 4b1a9: 83 c0 01 add $0x1,%eax 4b1ac: 89 85 f0 fd ff ff mov %eax,0xfffffdf0(%ebp) 4b1b2: 8d bd f8 fd ff ff lea 0xfffffdf8(%ebp),%edi 4b1b8: fc cld 4b1b9: b9 75 00 00 00 mov $0x75,%ecx 4b1be: f3 a5 repz movsl %ds:(%esi),%es:(%edi) 4b1c0: 83 7d 0c 00 cmpl $0x0,0xc(%ebp) 4b1c4: 0f 84 8c 00 00 00 je 4b256 <add_a_service+0xd8> 4b1ca: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp,1) as you can see, back in the days using gcc-3.3.3, the offset is properly "negatively high" enough (it is a signed long integer) to add the proper negative space to %ebp for storing the strings. The error can so be reproduced using the following test environment: Protector Patch for gcc-3.4.1 Gcc-3.4.2 Samba 3.0.7 Source Please tell us if this is a bug or error we have with using the protector patch for gcc-3.4.1 with gcc-3.4.2 or if this is a problem that was "added" when porting the protector patch to the gcc-3.4.x series. Thank you very much in advance, Alex
Hiroaki replied and will fix the error with the "broken" lea (load effective address) offset in the newer SSP versions. Thanks for your commitment to the hardened toolchain, even though it may look like containing a bit of suicidal tendencies in this bug report ;-) Alex
*** Bug 62109 has been marked as a duplicate of this bug. ***
*** Bug 64701 has been marked as a duplicate of this bug. ***
testing and trying to reproduce with default gcc for later upstream bug filing: # /usr/local/bin/gcc -v Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs Configured with: ../gcc-3.4.2/configure Thread model: posix gcc version 3.4.2
from objdump -S smbd <open_sockets_smbd> 280d5b: b9 20 00 00 00 mov $0x20,%ecx 280d60: 89 85 7c ed ff ff mov %eax,0xffffed7c(%ebp) 280d66: 89 c7 mov %eax,%edi 280d68: 8b 85 b0 ed ff ff mov 0xffffedb0(%ebp),%eax 280d6e: fc cld 280d6f: f3 ab repz stos %eax,%es:(%edi) seems to have been a gcc fault that has been solved in -r3 please test and close this bug to the discretion of the bug opener, i cannot reproduce the error in my chroots any more. gcc version 3.4.2 20041025 (Gentoo Hardened Linux 3.4.2-r3, ssp-3.4.1-1, pie-8.7.6.5) thank you, Alex
# as -v GNU assembler version 2.15.92.0.2 (i686-pc-linux-gnu) using BFD version 2.15.92.0.2 20040927 [ebuild R ] sys-devel/binutils-2.15.92.0.2-r1 -bootstrap -build -debug* -multitarget +nls (-uclibc) 0 kB as another hint, maybe the "as" was causing the problem.
Seems to be working fine for me now (been running for about 6 hours). Thanks for taking the time to understand the issue!
Jason, any concerns for the bug-wranglers to close the issue to your discretion? TIA, Alex
well unfortunately due to Bug #70446, i can't emerge it on the box to see if it works now (although my digest error is with the smbldap tools). i've been fighting with portage since last night trying to get it to merge. if you want to close it that's fine - i'll take the word of the other's above that it does work. if not, i guess i can re-open it. thanks for all your work.
disregard comment #32; compling samba now. i'll let you know shortly.
okie dokie... i recompiled samba-3.0.7-r1 (emerge info below). agreed, i no longer get the stack smashing errors in log.smbd, however this was fixed a long while ago. samba, however, will not authenticate against ADS with the hardened toolchain. i have the exact same setup (save hardened toolchain) on another box and it auth's against ADS flawlessly. i'm curious if the others for whom samba works with hardened use it with ADS as well. now, the affected box is a part of the domain - wbinfo works fine, i can join and leave the domain fine - but when it comes to accessing shares, it just doesn't work. i saw samba-3.0.8 was in the tree this AM, and after reviewing the offical samba release notes, i am hoping that the winbindd changes will help. sorry i can't be more helpful, but i'll do any testing i can and provide binpkg's/configs when asked for. thanks for your work.
sigh - forgot emerge info: System uname: 2.6.7-hardened-r7 i686 Intel(R) Xeon(TM) CPU 2.80GHz Gentoo Base System version 1.5.3 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.7-r4 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 apm avi berkdb bitmap-fonts crypt cups encode f77 foomaticdb fortran gdbm gif gpm gtk2 hardened imlib jpeg kerberos ldap libg++ libwww mad mikmod motif mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl pic png postgres python quicktime readline samba sdl slang snmp spell ssl svga tcpd truetype winbind x86 xml xml2 xmms xv zlib"
sheesh... forgot the top line of emerge info: Portage 2.0.51-r3 (default-x86-2004.2, gcc-3.4.3, glibc-2.3.4.20040619-r2, 2.6.7-hardened-r7 i686) sorry for the multiple posts.
