Summary: | Sylpheed-claws 0.9.12 stack smashing attack in quote_fmtparse | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Flammie Pirinen (RETIRED) <flammie> |
Component: | Current packages | Assignee: | Marius Mauch (RETIRED) <genone> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | alfons.clawzilla, colin |
Priority: | High | ||
Version: | 2004.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Test location of stack overrun
one problematic message New patch quote_fmt_parse.zip Re-organise quote_fmt_parse.y so to work with -fstack-protector |
Description
Flammie Pirinen (RETIRED)
![]() I need a backtrace, and also your quote format string to get a hint where the stack was smashed. Thanks! -- alfons Created attachment 45444 [details, diff]
Test location of stack overrun
Mmmh, I've got a hunch here.
Can you apply the attached patch, and see what happens next? (If it still
happens, try increasing the changed value - 1024 - to something bigger, say
2048 and on, in steps of *2).
(Note that you need to have flex and bison installed to get claws compile
again).
Thanks!
1024 does cause same problem still, strace ends like this, if it's of any help: stat64("/home/tpirinen/Mail/Gentoo/Doc+fi+cvs/22", {st_mode=S_IFREG|0600, st_size=6658, ...}) = 0 time(NULL) = 1102443722 stat64("/home/tpirinen/Mail/Gentoo/Doc+fi+cvs/22", {st_mode=S_IFREG|0600, st_size=6658, ...}) = 0 open("/home/tpirinen/Mail/Gentoo/Doc+fi+cvs/22", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0600, st_size=6658, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6911000 _llseek(8, 0, [0], SEEK_SET) = 0 read(8, "Return-path: <gentoo-doc-fi-retu"..., 4096) = 4096 close(8) = 0 munmap(0xb6911000, 4096) = 0 open("/home/tpirinen/Mail/Gentoo/Doc+fi+cvs/22", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0600, st_size=6658, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6911000 _llseek(8, 0, [0], SEEK_SET) = 0 read(8, "Return-path: <gentoo-doc-fi-retu"..., 1997) = 1997 read(8, "--------------enig31E3BE45C9BB48"..., 4096) = 4096 read(8, "nalisation Lead\n\\ http://www.ge"..., 4096) = 565 close(8) = 0 munmap(0xb6911000, 4096) = 0 open("/home/tpirinen/Mail/Gentoo/Doc+fi+cvs/22", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0600, st_size=6658, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6911000 _llseek(8, 0, [0], SEEK_SET) = 0 read(8, "Return-path: <gentoo-doc-fi-retu"..., 2128) = 2128 gettimeofday({1102443722, 741487}, NULL) = 0 open("/home/tpirinen/.sylpheed/mimetmp/sylpheed.dPkOBV", O_RDWR|O_CREAT|O_EXCL, 0600) = 10 fcntl64(10, F_GETFL) = 0x2 (flags O_RDWR) fstat64(10, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6910000 _llseek(10, 0, [0], SEEK_CUR) = 0 read(8, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4096) = 4096 write(10, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4017) = 4017 close(10) = 0 munmap(0xb6910000, 4096) = 0 close(8) = 0 munmap(0xb6911000, 4096) = 0 stat64("/home/tpirinen/.sylpheed/mimetmp/sylpheed.dPkOBV", {st_mode=S_IFREG|0600, st_size=4017, ...}) = 0 open("/home/tpirinen/.sylpheed/mimetmp/sylpheed.dPkOBV", O_RDONLY) = 8 fstat64(8, {st_mode=S_IFREG|0600, st_size=4017, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6911000 _llseek(8, 0, [0], SEEK_SET) = 0 open("/home/tpirinen/.sylpheed/mimetmp/00000000.mimetmp", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10 read(8, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4096) = 4017 fstat64(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6910000 close(8) = 0 munmap(0xb6911000, 4096) = 0 write(10, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4017) = 4017 close(10) = 0 munmap(0xb6910000, 4096) = 0 open("/home/tpirinen/.sylpheed/mimetmp/00000000.mimetmp", O_RDONLY) = 8 open("/home/tpirinen/.sylpheed/tmp/sylpheed-claws.WbLclR", O_RDWR|O_CREAT|O_EXCL, 0600) = 10 unlink("/home/tpirinen/.sylpheed/tmp/sylpheed-claws.WbLclR") = 0 fcntl64(10, F_GETFL) = 0x2 (flags O_RDWR) fstat64(10, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6911000 _llseek(10, 0, [0], SEEK_CUR) = 0 fstat64(8, {st_mode=S_IFREG|0644, st_size=4017, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6910000 read(8, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4096) = 4017 read(8, "", 4096) = 0 close(8) = 0 munmap(0xb6910000, 4096) = 0 write(10, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4017) = 4017 _llseek(10, 0, [0], SEEK_SET) = 0 unlink("/home/tpirinen/.sylpheed/mimetmp/00000000.mimetmp") = 0 unlink("/home/tpirinen/.sylpheed/mimetmp/sylpheed.dPkOBV") = 0 read(10, "Flammie Pirinen wrote:\n> Ahh, I\'"..., 4096) = 4017 read(10, "", 4096) = 0 close(10) = 0 munmap(0xb6911000, 4096) = 0 rt_sigprocmask(SIG_BLOCK, ~[ABRT RTMIN], NULL, 8) = 0 write(2, "sylpheed-claws: stack smashing a"..., 64sylpheed-claws: stack smashing attack in function quote_fmtparse) = 64 write(2, "()\n", 3() ) = 3 socket(PF_UNIX, SOCK_DGRAM, 0) = 8 sendto(8, "<2>sylpheed-claws: stack smashin"..., 67, 0, {sa_family=AF_UNIX, path="/dev/log"}, 110) = 67 rt_sigaction(SIGABRT, {SIG_DFL}, NULL, 8) = 0 kill(7286, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ gdb's backtrace's unfortunately less than informative at the moment, odd, since I tried to get all debug info possible in...: #0 0xffffe410 in ?? () #1 0xbffc96c8 in ?? () #2 0xb7919860 in ?? () from /lib/libc.so.6 #3 0x00000006 in ?? () #4 0xb782b936 in kill () from /lib/libc.so.6 #5 0xb7817663 in __stack_smash_handler () from /lib/libc.so.6 #6 0x081529ce in quote_fmtparse () #7 0x7542202e in ?? () #8 0x68742074 in ?? () #9 0x73277461 in ?? () #10 0x73756a20 in ?? () #11 0x68742074 in ?? () #12 0x49207461 in ?? () #13 0x6c206d27 in ?? () #14 0x20737365 in ?? () #15 0x75716361 in ?? () #16 0x746e6961 in ?? () #17 0x74206465 in ?? () #18 0x6f77206f in ?? () #19 0x6e696b72 in ?? () #20 0x69772067 in ?? () #21 0x62206874 in ?? () #22 0x697a6775 in ?? () #23 0x20616c6c in ?? () #24 0x6e616874 in ?? () #25 0x61204920 in ?? () #26 0x6977206d in ?? () #27 0x65206874 in ?? () #28 0x6c69616d in ?? () #29 0x73000a2e in ?? () #30 0x6d656863 in ?? () #31 0x36202c65 in ?? () #32 0x74732029 in ?? () #33 0x20747261 in ?? () #34 0x6e617274 in ?? () #35 0x74616c73 in ?? () #36 0x2f676e69 in ?? () #37 0x64616572 in ?? () #38 0x2e676e69 in ?? () #39 0x65685420 in ?? () #40 0x6f687320 in ?? () #41 0x72657472 in ?? () #42 0x65687420 in ?? () #43 0x72656d20 in ?? () #44 0x72656972 in ?? () #45 0x08000a2e in ?? () #46 0x082f2528 in ?? () #47 0x082f4988 in ?? () What do you mean by quote format string? This is reply format: %D{%Y-%m-%d}, %N sanoi, jotta: %Q And characters to be treated as quotes are: >|} Yes, that's what I meant by "quote format string" - thanks. Can you point me (URL link) to the offending message, or gzip-attach the offending message to this report? Also, I'd very much appreciate it if you could do a final test of increasing the buffer size to say, 10K (10 * 1024), or higher. Again, thanks. example of offending message: http://article.gmane.org/gmane.linux.gentoo.documentation.finnish/18 , hopefully this is enough. If not, I can try to dump raw message as attachment or something. Same problem appears with 4k patch I tried, and I can't quite figure why I won't get any debug data, there is no stripping options and I even't tried to add -g switch to compiler. 10K? (Obviously some of the lines in the message are rather large.) Also, yes, please attach the original message to this bug report. Created attachment 45487 [details]
one problematic message
This is one of those messages that unconditionally breaks. Just tested and the
b0rkage does happen even with 10k patch set.
Created attachment 45521 [details, diff]
New patch
Can you try the attached patch?
I could not reproduce the problem with your message, probably because of my
compiler (gcc 3.3.1).
Try to attach gdb to a running sylpheed-claws, and also, make sure you started
sylpheed-claws with environment variable SYLPHEED_NO_CRASH=1 set:
% SYLPHEED_NO_CRASH=1 [path/to/]sylpheed
Thanks again.
It still seems to crash, and no matter which pid I try to get with gdb, it still produces the same useless backtrace... Unfortunately I haven't got time to study the problem further at the moment. #0 0xffffe410 in ?? () #1 0xbffef158 in ?? () #2 0xb7919860 in ?? () from /lib/libc.so.6 #3 0x00000006 in ?? () #4 0xb782b936 in kill () from /lib/libc.so.6 #5 0xb7817663 in __stack_smash_handler () from /lib/libc.so.6 #6 0x081529de in quote_fmtparse () at quote_fmt_parse.c:2077 #7 0x7542202e in ?? () #8 0x68742074 in ?? () ... #46 0x082f2528 in ?? () #47 0x082f4988 in ?? () It seems I had had stripping turned on from portage as well. Hopefully this info will help. Thanks!!! Now can you get ten / twelve lines around quote_fmt_parse.c line 2077 (see your excellent trace). The problem is that quote_fmt_parse.c is generated from quote_fmt_parse.y. (or if it's not that big, zip quote_fmt_parse.c and attach it to the bug report.) Thanks again. Oddly enough, the line 2077 contains only final closing brace here...: #ifndef yyoverflow /*----------------------------------------------. | yyoverflowlab -- parser overflow comes here. | `----------------------------------------------*/ yyoverflowlab: yyerror ("parser stack overflow"); yyresult = 2; /* Fall through. */ #endif yyreturn: #ifndef yyoverflow if (yyss != yyssa) YYSTACK_FREE (yyss); #endif return yyresult; } or is there yet something else meddling with line numbers? I'll attach the zip for reference anyways. Created attachment 45689 [details]
quote_fmt_parse.zip
Contains whole generated quote_fmt_parse.c as picked from portage's working
directory.
Created attachment 45697 [details, diff]
Re-organise quote_fmt_parse.y so to work with -fstack-protector
To help you out a bit compiled and installed gcc 3.4.2 with the stack protector
patch; I found the same error.
It seems that the stack-protector code doesn't like bulky functions with lots
of local blocks with each allocating auto vars (stack vars). Breaking down the
parser functions in smaller functional units, always a good idea, seems to fix
the "error". Please check if this patch works for you.
Colin, can you double-check the patch too?
Thanks.
The patch keeps rejecting at first name, last name and middle initial. It seems to have been changed in rev 1.25 in your cvs. I'm manually pulling 1.22.5 indicated in patch header and using that one. Works for me now. Thanks. Thanks! Colin: Send it to Hoa? Or just commit to HEAD and gtk2 after checking it a bit. It looks ok to me, but I'd rather have Hoa check it: I didn't touch this code very much... This is fixed in sylpheed CVS, see here: http://sourceforge.net/mailarchive/forum.php?thread_id=6140581&forum_id=33125 and http://sourceforge.net/mailarchive/forum.php?thread_id=6146905&forum_id=33125 closing then |