Hello,
I can reproduce this bug.
With both exim4 and gnutls-serv.
/home/murble# /usr/sbin/exim4 -bh 23.23.23.23
**** SMTP testing session as if from host 23.23.23.23
**** but without any ident (RFC 1413) callback.
**** This is not for real!
>>> host in hosts_connection_nolog? no (option unset)
>>> host in host_lookup? yes (matched "*")
>>> looking up host name for 23.23.23.23
>>> IP address lookup using gethostbyaddr()
>>> IP address lookup failed: h_errno=1
LOG: no host name found for IP address 23.23.23.23
>>> host in host_reject_connection? no (option unset)
>>> host in sender_unqualified_hosts? no (option unset)
>>> host in recipient_unqualified_hosts? no (option unset)
>>> host in helo_verify_hosts? no (option unset)
>>> host in helo_try_verify_hosts? no (option unset)
>>> host in helo_accept_junk_hosts? no (option unset)
220 boughton.de ESMTP Exim 4.66 Fri, 02 Feb 2007 17:16:28
+0000
ehlo foo
>>> foo in helo_lookup_domains? no (end of list)
>>> host in pipelining_advertise_hosts? yes (matched "*")
>>> host in auth_advertise_hosts? yes (matched "*")
>>> host in tls_advertise_hosts? yes (matched "*")
>>> host in tls_advertise_hosts? yes (matched "*")
250-boughton.de Hello foo [23.23.23.23]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN
250-STARTTLS
250 HELP
STARTTLS
Segmentation fault (core dumped)
Core was generated by `/usr/sbin/exim4 -bh 23.23.23.23'.
Program terminated with signal 11, Segmentation fault.
#0 0x00002b4a8c20e748 in memmem () from /lib/libc.so.6
(gdb) bt
#0 0x00002b4a8c20e748 in memmem () from /lib/libc.so.6
#1 0x00002b4a8c402f34 in _gnutls_fbase64_decode ()
from /usr/lib/libgnutls.so.13
#2 0x00002b4a8c4271e7 in gnutls_x509_crt_import ()
from /usr/lib/libgnutls.so.13
#3 0x00002b4a8c412e7f in gnutls_certificate_set_x509_crl_mem ()
from /usr/lib/libgnutls.so.13
#4 0x00002b4a8c4141ad in gnutls_certificate_set_x509_trust_file ()
from /usr/lib/libgnutls.so.13
#5 0x000000000046b2fb in tls_init (host=0x0,
certificate=0x5e8078 "/etc/ssl/certs/mail.crt",
privatekey=0x5e80a0 "/etc/ssl/private/mail.key",
cas=0x5e8170 "${if
exists{/etc/ssl/certs/ca-certificates.crt}{/etc/ssl/certs/ca-certificates.crt}{/dev/null}}",
crl=0x0) at tls-gnu.c:487
#6 0x000000000046c2fc in tls_server_start (require_ciphers=0x0)
at tls-gnu.c:773
#7 0x0000000000461f3b in smtp_setup_msg () at smtp_in.c:3497
#8 0x0000000000430536 in main (argc=3, cargv=<value optimized out>)
at exim.c:4380
ii libgnutls13 1.4.4-3 the GNU TLS library - runtime library
ii ca-certificate 20061027 Common CA Certificates PEM files
With my own CA file installed...
It appears to be a problem with malformed pem files, i tried this
test:
cp boughton-ca-cert.pem /tmp/a
openssl x509 -in /tmp/a >/tmp/b
diff -u /tmp/a /tmp/b
diff -u /tmp/a /tmp/b
--- /tmp/a 2007-02-02 17:24:37.000000000 +0000
+++ /tmp/b 2007-02-02 17:24:37.000000000 +0000
@@ -1,4 +1,4 @@
------BEGIN CERTIFICATE----- <- white space
+-----BEGIN CERTIFICATE-----
Copying the /tmp/b back to the boughton-ca-cert.pem file and
rerunning /usr/sbin/update-ca-certificates makes the problem go away.
Normally when i try and corrupt a file on purpose
LOG: TLS error on connection from (asfd) [23.23.23.23] (setup_certs):
Base64 decoding error.
This is also reproduceable with gnutls-bin
Core was generated by `gnutls-serv --x509cafile ca-certificates.crt'.
Program terminated with signal 11, Segmentation fault.
#0 0x00002b941e51b748 in memmem () from /lib/libc.so.6
(gdb) bt
#0 0x00002b941e51b748 in memmem () from /lib/libc.so.6
#1 0x00002b941dca7f34 in _gnutls_fbase64_decode ()
from /usr/lib/libgnutls.so.13
#2 0x00002b941dccc1e7 in gnutls_x509_crt_import ()
from /usr/lib/libgnutls.so.13
#3 0x00002b941dcb7e7f in gnutls_certificate_set_x509_crl_mem ()
from /usr/lib/libgnutls.so.13
#4 0x00002b941dcb91ad in gnutls_certificate_set_x509_trust_file ()
from /usr/lib/libgnutls.so.13
#5 0x0000000000406e48 in ?? ()
#6 0x00002b941e4c34ca in __libc_start_main () from /lib/libc.so.6
#7 0x0000000000403fca in ?? ()
#8 0x00007fffffe893e8 in ?? ()
#9 0x0000000000000000 in ?? ()
http://www.yuri.org.uk/~murble/ca-certificates.crt.txt for the file
that reproduces this bug.
cheers
Bill
--
Bill Boughton <[EMAIL PROTECTED]>
Germany: +49 (0)9252 3575797 / UK: +44 (0)20 7043 6412
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
