Supybot is problematic with -fstack-protector. Many plugins and even the main routine to the following strace backtrace: unlink("/usr/lib/python2.3/site-packages/supybot/plugins/FunDB.pyc") = -1 ENOENT (No such file or directory) open("/usr/lib/python2.3/site-packages/supybot/plugins/FunDB.pyc", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) kill(10177, SIGRTMIN) = 0 gettimeofday({1078258357, 475146}, NULL) = 0 gettimeofday({1078258357, 476080}, NULL) = 0 gettimeofday({1078258357, 476666}, NULL) = 0 gettimeofday({1078258357, 478910}, NULL) = 0 gettimeofday({1078258357, 479086}, NULL) = 0 gettimeofday({1078258357, 479617}, NULL) = 0 gettimeofday({1078258357, 479781}, NULL) = 0 close(24) = 0 munmap(0x20a1a000, 4096) = 0 open("/home/phil/supybot/logs/plugins/FunDB.log", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666python: stack smashing attack in function call_function() ) = 24 fstat64(24, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20a1a000 fstat64(24, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 _llseek(24, 0, [0], SEEK_SET) = 0 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] I can't tell why it does this. It's also upon load of some plugins. Could be a security bug?
is it something with python that is causing this? i can't imagine a python script activating something like that. although it does look like it is retrying to delete the .pyc file for that script.
Other python things like portage do not break with stack-protector. Supybot was started as a normal user. You shouldn't start something like it as root, or was this intended? There is - however - no log entry about this issue in the syslog (but I don't think that stack protector does it - in contrary to grsecurity). I think the hardened guys should look about this first before we do some random guesses (I only guess it's the stack-protector, but it runs at your site - and it's Stack Smashing.)
find the open call in the call_function function and compare the value in the strace to the buffer and buffer size used use FEATURES="keeptemp keepwork" in your make.conf or directly on command line to keep the source build with CFLAGS -g -ggdb do not use optimization at first hand open("/home/phil/supybot/logs/plugins/FunDB.log", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666python: stack smashing attack in function call_function() this is the line i am talking about take a quick shot from the hip and see if the buffer is REALLY too long SSP is very itchy about long buffers, that is what it has been designed for ;-) you can also single step the call_function and compare the value from the __guard to the copied canary on the stack, represented by the mov value in assembler, but if you leave that to the pro's, just look at the source first and then tell me to get my hands into it thank you for supporting us, Alex
pappy, do you want to take this bug? i have no idea about how stack smashing stuff works under linux
what is the status with the tests i have been asking for?
I wanted to do them yesterday/today but some guy killed the sshd. ;) I'll do them in at max. two days time (hopefully still today).
The function is in libpython2.3.so.1.0, how could I set a break point in gdb for python2.3 then? The attach to a crashed supybot only mentions addresses but no code or something.
you should compile python the same way with -g -ggdb like you did with the app you have to compile everything involved with debugging to be a good bug helper :-) preferably also the glibc thanks in advance, Alex
I didn't tell emerge info at first hand. This was a mistake I think. Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.4.22-gentoo-r7) ================================================================= System uname: 2.4.22-gentoo-r7 i686 Pentium III (Katmai) Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe -fomit-frame-pointer -frerun-loop-opt -falign-functions=4 -fforce-mem -ffast-math -finline-functions -foptimize-sibling-calls -mmmx -fstack-protector" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/afs/C /etc/afs/afsws /etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe -fomit-frame-pointer -frerun-loop-opt -falign-functions=4 -fforce-mem -ffast-math -finline-functions -foptimize-sibling-calls -mmmx -fstack-protector -Wno-deprecated" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl apache2 berkdb crypt exiscan-acl gd gdbm gif gtk2 imap imlib innodb ipv6 jpeg libwww maildir mbox memlimit mysql ncurses nls oss pam pdflib perl png python readline ruby slang sse ssl tcpd x86 xml2 xmms zlib" But anyway I had few issues with this settings. But after a recompile of python (only python) with -g -ggdb as the only cflags it still didn't work, that's what I stated. A additional recompile of supybot with -g -ggdb which I didn't do first as I didn't thought of compiled things on a python bug solved the issue and now the bot works without crashing. So I'll recompile python with -fstack-protector (blame me, yes) and also supybot in one of the next days. Stay tuned ;)
I'll be back on the 20th of March and then look again into this. Sorry for not providing useful information so far, but I'll do as soon as possible. Please just let this one open. Thanks.
I know this is no good for the propolice/hardened team -- which by now did an excellent work, the few bugs I encountered on my machines were fixed quite quickly, but I currently do not have the time, so my efforts on this one are few. This one is complicated as it required several rebuilds. I'm sorry. Anybody who also steps over this problem should add himself as Cc. I could then look again into this. Thus I'll close this as RESOLVED NEEDINFO.
