Because my setup is not really standard - I'm not asking for any support. This ticket is more or less to inform you about potential problem (unless someone can reproduce the issue). My setup is based on 2008 hardened profile (SELinux and Pax) + lots of hardening parches to glibc 2.9 (mainly from secure overlay) + gcc 4.3.3 (also hardened, where most patches come from secure overlay). This setup - although not really standard is very stable for me and I never had any real issues with it. Before posting that patch I've tried to debug it as much as possible. After updating courier-imap to 4.4.1 (4.4.1 and 4.4.1-r1 are identical - not sure why) I've got stack smashing detected every time client tries to start TLS. Mar 24 20:20:24 [imapd-ssl] *** stack smashing detected ***: couriertls - terminated Mar 24 20:20:24 [imapd-ssl] couriertls: stack smashing attack in function <unknown> - terminated Mar 24 20:20:24 [imapd-ssl] Report to http://bugs.gentoo.org/ What I've done so far: 1) I've tried reinstalling/upgrading gnutls. The result was the same. 2) I've tried to get any backtrace from gdb, but due to the way couriertls is spawned (only during client connection) it was impossible. 3) I've tried getting any straces (file attached). 4) I've tried forcing it to core dump (as suggested by gengor) with ulimit -c unlimited > core_dump 2>&1 , but no luck. File was created, but size was always 0. I've also tried running server manually (not using init script) and managed to achieve the following results - and I could reliably reproduce it every time: Mar 24 20:52:19 [imapd-ssl] Could not negotiate a supported cipher suite. It seems the problem lies in cipher negotiation. I also tried reinstalling courier-imap without gnutls support (so it can use openssl), but the results were identical. At the end I had to downgrade version to 4.1.2-r1 which works correctly: round cube: Mar 25 00:35:37 [imapd-ssl] Connection, ip=[::ffff:127.0.0.1] Mar 25 00:35:37 [imapd-ssl] LOGIN, user=dagger, ip=[::ffff:127.0.0.1], protocol=IMAP Mar 25 00:35:51 [imapd-ssl] LOGOUT, user=dagger, ip=[::ffff:127.0.0.1], headers=14755, body=0, rcvd=535, sent=42769, time=14, starttls=1 kmail: Mar 25 00:36:26 [imapd] Connection, ip=[::ffff:192.168.1.100] Mar 25 00:36:29 [imapd] Disconnected, ip=[::ffff:192.168.1.100], time=3, starttls=1 Interesting fact is, it "works" (by works I mean doesn't cry about stack) when you run it from command line and not an init script (I'm assuming it has something to do with sourcing /etc/courier/imap{-ssl} files. When I run it from command line, config files were not sources and ciphers were not set. Later on, I also tried setting all possible combination of ciphers in config file, but result was always the same - stack smashing detected). Anyway, if someone could reproduce that would be great. Thanks, Rob Reproducible: Always
Created attachment 186162 [details] strace
It could be related to a problem I've not yet been able to debug, which seems to have something to do with the way courier-imap interacts with gnutls. I managed to get a backtrace back in August 2008, but haven't had a chance to look at it since then, and went back to courier-imap-4.1.2-r2 (though had to hack the ebuild to get it to compile... see #226127). gdb /usr/sbin/couriertls 28309 GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Attaching to program: /usr/sbin/couriertls, process 28309 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Executing new program: /usr/sbin/couriertls.orig Program received signal SIGSEGV, Segmentation fault. 0x0804cbd8 in gen_encryption_desc (session=0x8075060, dump_func=0x804cbd8 <gen_encryption_desc+67>, dump_arg=0xbf5ba904) at libcouriergnutls.c:2231 2231 (*dump_func)(",", 1, dump_arg); (gdb) bt #0 0x0804cbd8 in gen_encryption_desc (session=0x8075060, dump_func=0x804cbd8 <gen_encryption_desc+67>, dump_arg=0xbf5ba904) at libcouriergnutls.c:2231 #1 0x0804cc92 in tls_get_encryption_desc (ssl=0x8074fb0) at libcouriergnutls.c:2216 #2 0x0804b77b in verify_connection (ssl=0x8074fb0, dummy=0x0) at starttls.c:322 #3 0x0804db97 in dohandshake (ssl=0x8074fb0, fd=0, r=0xbf5baeb0, w=0xbf5bae30) at libcouriergnutls.c:1049 #4 0x0804dbe0 in tls_transfer (t=0xbf5baf64, ssl=0x8074fb0, fd=0, r=0xbf5baeb0, w=0xbf5bae30) at libcouriergnutls.c:1771 #5 0x0804c1e6 in dossl (fd=0, argn=6, argc=6, argv=0xbf5bb124) at starttls.c:477 #6 0x0804c737 in main (argc=6, argv=0xbf5bb124) at starttls.c:801 (gdb) print *(char**)dump_arg $1 = 0x807aa10 "Â \001(@Â \001(@" Robert, you could try not linking against gnutls (but see #237937).
Please retry with 4.16.2-r1
