Bug#402665: STARTTLS causes segfault

2006-12-11 Thread peterc

Package: exim4-daemon-heavy
Version: 4.63-11

When I try to send authenticated email through my server using TLS,
the server crashes.

libgnutls13 version is 1.4.4-3
Reverting to 1.4.2-2 solves the problem.

Feel free to reassign this problem to gnutls13 if the problem's
really there.

Here's an strace:

read(5, "ehlo croc\r\n", 8192)  = 11
alarm(0)= 259
rt_sigaction(SIGALRM, {0x806df40, [], 0}, NULL, 8) = 0
rt_sigaction(SIGALRM, {0x80abe30, [], 0}, NULL, 8) = 0
write(3, "250-mx.chubb.wattle.id.au Hello "..., 139) = 139
alarm(300)  = 0
read(5, "starttls\r\n", 8192)   = 10
alarm(0)= 291
rt_sigaction(SIGALRM, {0x806df40, [], 0}, NULL, 8) = 0
brk(0x815b000)  = 0x815b000
access("/dev/random", R_OK) = 0
access("/dev/urandom", R_OK)= 0
open("/dev/urandom", O_RDONLY)  = 4
select(5, [4], NULL, NULL, {3, 0})  = 1 (in [4], left {3, 0})
read(4, "\34\254\3101\307\206+m\247\307\223\346\335\255\327\374"..., 120) = 120
select(5, [4], NULL, NULL, {3, 0})  = 1 (in [4], left {3, 0})
read(4, "m\374\2439\223\335\325\367\10\2518\22\377\17\330\235\'"..., 120) = 120
select(5, [4], NULL, NULL, {3, 0})  = 1 (in [4], left {3, 0})
read(4, "fPUwJ\313\23\37U\35#w\23\277{u\34\22\370\243{\217e\24\265"..., 120) = 
120
select(5, [4], NULL, NULL, {3, 0})  = 1 (in [4], left {3, 0})
read(4, "4f\n\352\253Y\250m\\K\24\264/\213\252A\2\255\371\341\272"..., 120) = 
120
select(5, [4], NULL, NULL, {3, 0})  = 1 (in [4], left {3, 0})
read(4, "ZVH\'\240\336\326\263\245\245\36pVze\3719\344?\223\272"..., 120) = 120
gettimeofday({1165879251, 31140}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 1}, ru_stime={0, 0}, ...}) = 0
time(NULL)  = 1165879251
times({tms_utime=1, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 691262857
--- SIGSEGV (Segmentation fault) @ 0 (0) ---


Here's a little of the debug output for that conversation:
Exim version 4.63 uid=0 gid=0 pid=18252 D=fbb95cfd
Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September  6, 2005)
Support for: crypteq iconv() IPv6 PAM Perl GnuTLS move_frozen_messages Content_S
canning Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch 
ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
changed uid/gid: forcing real = effective
  uid=0 gid=0 pid=18252
  auxiliary group list: 
seeking password data for user "uucp": cache not available
getpwnam() succeeded uid=10 gid=10
configuration file is /var/lib/exim4/config.autogenerated
log selectors = 0ffc 00089001
cwd=/etc/exim4 3 args: exim4 -bd -d
trusted user
admin user
seeking password data for user "mail": cache not available
getpwnam() succeeded uid=8 gid=8
user name "root" extracted from gecos field "root"
originator: uid=0 gid=0 login=root name=root
18252 LOG: MAIN
18252   IPv6 socket creation failed: Address family not supported by protocol
18252 LOG: MAIN
18252   Failed to create IPv6 socket for wildcard listening (Address family not 
supported by protocol): will use IPv4
18252 listening on all interfaces (IPv4) port 25
18252 pid written to /var/run/exim4/exim.pid
18252 changed uid/gid: running as a daemon
18252   uid=103 gid=103 pid=18252
18252   auxiliary group list: 103
18252 LOG: MAIN
18252   exim 4.63 daemon started: pid=18252, no queue runs, listening for SMTP o
n port 25 (IPv4)
18252 set_process_info: 18252 daemon: no queue runs, listening for SMTP on port 
25 (IPv4)
18252 daemon running with uid=103 gid=103 euid=103 egid=103
18252 Listening...
18252 Connection request from 203.143.174.122 port 46735
18252 search_tidyup called
18255 sender_fullhost = [203.143.174.122]
18255 sender_rcvhost = [203.143.174.122]
18255 Process 18255 is handling incoming connection from [203.143.174.122]
18255 host in host_lookup? yes (matched "*")
18255 looking up host name for 203.143.174.122
18252 1 SMTP accept process running
18252 Listening...
18255 DNS lookup of 122.174.143.203.in-addr.arpa (PTR) succeeded
18255 IP address lookup yielded research-remote.nicta.com.au
18255 gethostbyname2(af=inet6) returned 4 (NO_DATA)
18255 gethostbyname2 looked up these IP addresses:
18255   name=research-remote.nicta.com.au address=203.143.174.122
18255 checking addresses for research-remote.nicta.com.au
18255   203.143.174.122 OK
18255 sender_fullhost = research-remote.nicta.com.au [203.143.174.122]
18255 sender_rcvhost = research-remote.nicta.com.au ([203.143.174.122])
18255 set_process_info: 18255 handling incoming connection from research-remote.
nicta.com.au [203.143.174.122]
18255 host in host_reject_connection? no (option unset)
18255 host in sender_unqualified_hosts? no (option un

Bug#402665: STARTTLS causes segfault

2006-12-12 Thread Marc Haber
package exim4-daemon-heavy
reassign #402665 libgnutls13
thanks

On Tue, Dec 12, 2006 at 10:55:31AM +1100, [EMAIL PROTECTED] wrote:
> Package: exim4-daemon-heavy
> Version: 4.63-11
> 
> When I try to send authenticated email through my server using TLS,
> the server crashes.
> 
> libgnutls13 version is 1.4.4-3
> Reverting to 1.4.2-2 solves the problem.
> 
> Feel free to reassign this problem to gnutls13 if the problem's
> really there.



Since going back to libgnutls13 1.4.2-2 solves the problem, and exim
hasn't changed there in a long time, I really really suspect a gnutls
issue.

I am therefore reassigning the bug.

GnuTLS people, if you disagree, please move the bug back to
exim4-daemon-heavy and notify [EMAIL PROTECTED]

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: STARTTLS causes segfault

2006-12-12 Thread Andreas Metzler
On 2006-12-12 [EMAIL PROTECTED] wrote:
> Package: exim4-daemon-heavy
> Version: 4.63-11

> When I try to send authenticated email through my server using TLS,
> the server crashes.

> libgnutls13 version is 1.4.4-3
> Reverting to 1.4.2-2 solves the problem.

Would you mind testing against the interim versions of libgnutls13,
too?

After adding

deb http://snapshot.debian.net/archive pool gnutls13
to /etc/apt/sources.list running through them by using e.g.
apt-get install libgnutls13=1.4.4-1

should not be too painful.

Hmm. I just realized that there never was a 1.4.2-2 version. - Is
 this a typo?

> Feel free to reassign this problem to gnutls13 if the problem's
> really there.
[...]

Looks like it is.
cu andreas
PS: James, I won't have a lot of time to spare on debugging this until
saturday. - Feel free to jump in. ;-) Thanks.
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: STARTTLS causes segfault

2007-02-03 Thread Andreas Metzler
On 2007-02-02 William Boughton <[EMAIL PROTECTED]> wrote:
> I can reproduce this bug.
[...]
> ii  libgnutls131.4.4-3the GNU TLS library - runtime library
> ii  ca-certificate 20061027   Common CA Certificates PEM files
[...]
> This is also reproduceable with gnutls-bin
> Core was generated by `gnutls-serv --x509cafile ca-certificates.crt'.
> Program terminated with signal 11, Segmentation fault.
[...]
> http://www.yuri.org.uk/~murble/ca-certificates.crt.txt for the file
> that reproduces this bug.

What arch are you on? I do not see this on etch/ix86.

ii  libgnutls131.4.4-3
[EMAIL PROTECTED]:/tmp$ gnutls-serv --x509cafile
ca-certificates.crt.txt
Error reading 'ca-certificates.crt.txt'
Error: Base64 decoding error.

thanks, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: STARTTLS causes segfault

2007-02-03 Thread William Boughton
On Sat, Feb 03, 2007 at 10:30:59AM +0100, Andreas Metzler wrote:
> On 2007-02-02 William Boughton <[EMAIL PROTECTED]> wrote:
> > I can reproduce this bug.
> [...]
> > ii  libgnutls131.4.4-3the GNU TLS library - runtime library
> > ii  ca-certificate 20061027   Common CA Certificates PEM files
> [...]
> > This is also reproduceable with gnutls-bin
> > Core was generated by `gnutls-serv --x509cafile ca-certificates.crt'.
> > Program terminated with signal 11, Segmentation fault.
> [...]
> > http://www.yuri.org.uk/~murble/ca-certificates.crt.txt for the file
> > that reproduces this bug.
> 
> What arch are you on? I do not see this on etch/ix86.

x86_64
Linux test 2.6.18-3-xen-amd64 #1 SMP Mon Dec 4 17:56:42 CET 2006 x86

on:
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 35
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping: 2
cpu MHz : 2399.822
cache size  : 512 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36
clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext
3dnow pni lahf_lm cmp_legacy
bogomips: 6001.45
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

ii  libc6  2.3.6.ds1-10   GNU C Library: Shared libraries
ii  gnutls-bin 1.4.4-3the GNU TLS library - commandline utilities


I debootstrapped a clean etch and I still get this.  
This machine is running under Xen so i  got someone else to test it on an 
unstable chroot on an amd64 machine not running Xen.

I have been unable to reproduce this on x86_32.  It also doesn't
happen in a x86_32 etch chroot on the same machine amd64(x86_64).


regards

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]



Bug#402665: STARTTLS causes segfault

2007-02-04 Thread Andreas Metzler
On 2007-02-03 William Boughton <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 03, 2007 at 10:30:59AM +0100, Andreas Metzler wrote:
[...] 
>> What arch are you on? I do not see this on etch/ix86.

> x86_64
[...]
> I have been unable to reproduce this on x86_32.  It also doesn't
> happen in a x86_32 etch chroot on the same machine amd64(x86_64).

Hello,
I could reproduce this on pergolesi.debian.org's amd64 chroots with
1.4.4 however there is currently some stuff missing for properly
debugging it. I have emailed debian-admin to get it installed.

It seems to be fixed in 1.6.x. - Could you install libgnutls13 from
experimental and verify that you cannot reproduce it with this version
either?
thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: STARTTLS causes segfault

2007-02-04 Thread William Boughton
On Sun, Feb 04, 2007 at 12:04:09PM +0100, Andreas Metzler wrote:
> On 2007-02-03 William Boughton <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 03, 2007 at 10:30:59AM +0100, Andreas Metzler wrote:
> > x86_64
> Hello,
> I could reproduce this on pergolesi.debian.org's amd64 chroots with
> 1.4.4 however there is currently some stuff missing for properly
> debugging it. I have emailed debian-admin to get it installed.
> 
> It seems to be fixed in 1.6.x. - Could you install libgnutls13 from
> experimental and verify that you cannot reproduce it with this version
> either?

Setting up libgnutls13 (1.6.0-1) ...

[EMAIL PROTECTED]:~/tmp$ gnutls-serv --x509cafile ca-certificates.crt.txt 
Error reading 'ca-certificates.crt.txt'
Error: Base64 decoding error.

So it seems to fix that.

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]



Bug#402665: STARTTLS causes segfault

2007-02-04 Thread Andreas Metzler
On 2007-02-04 Andreas Metzler <[EMAIL PROTECTED]> wrote:
> On 2007-02-03 William Boughton <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 03, 2007 at 10:30:59AM +0100, Andreas Metzler wrote:
> [...] 
> >> What arch are you on? I do not see this on etch/ix86.

> > x86_64
> [...]
> > I have been unable to reproduce this on x86_32.  It also doesn't
> > happen in a x86_32 etch chroot on the same machine amd64(x86_64).

> Hello,
> I could reproduce this on pergolesi.debian.org's amd64 chroots with
> 1.4.4 however there is currently some stuff missing for properly
> debugging it. I have emailed debian-admin to get it installed.

I have used LD_LIBRARY_PATH as workaround.
As you have already noted the trrigger is the very last certificate in
the file

-BEGIN CERTIFICATE-   < note whitespace here!
MIIDmTCCAwKgAwIBAgIJAMyJZWWIII1aMA0GCSqGSIb3DQEBBAUAMIGQMQswCQYD
[...]

The actual crash happens in x509_b64.c:479 _gnutls_fbase64_decode()
since it somehow gets passed on the wrong data_size=1475 (instead of the
correct data_size=1313).

> It seems to be fixed in 1.6.x.
[...]

This patch in 1.6.x and later versions seems to fix the issue:

2006-06-16  Simon Josefsson <[EMAIL PROTECTED]>

* configure.in, lib/Makefile.am, lib/gnutls_x509.c,
libextra/gnutls_openpgp.c: Use read_binary_file from gnulib instead
of strfile stuff, to fix problem with binary files on mingw.

I am not sure about the severity of this bug, whether we should try to
squeeze the fix into etch.

cu and- fix pulled from cvs attached -reas

cvs diff -D 'Jun 16 13:27:36 2006 UTC' -D 'Jun 16 13:33:36 2006 UTC'
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Index: configure.in
===
RCS file: /cvs/gnutls/gnutls/configure.in,v
retrieving revision 2.420
retrieving revision 2.421
diff -u -r2.420 -r2.421
--- configure.in	16 Jun 2006 12:16:16 -	2.420
+++ configure.in	16 Jun 2006 13:29:35 -	2.421
@@ -183,7 +183,7 @@
 AC_CHECK_HEADERS(math.h limits.h float.h stdarg.h ctype.h)
 dnl opencdk
 AC_CHECK_HEADERS(netdb.h)
-AC_CHECK_FUNCS(umask vasprintf isascii mmap gmtime_r,,)
+AC_CHECK_FUNCS(umask vasprintf isascii gmtime_r,,)
 AC_FUNC_ALLOCA
 
 AC_MSG_RESULT([***
Index: lib/Makefile.am
===
RCS file: /cvs/gnutls/gnutls/lib/Makefile.am,v
retrieving revision 2.181
retrieving revision 2.182
diff -u -r2.181 -r2.182
--- lib/Makefile.am	15 Jun 2006 16:02:11 -	2.181
+++ lib/Makefile.am	16 Jun 2006 13:29:36 -	2.182
@@ -84,9 +84,9 @@
 	gnutls_extensions.h gnutls_buffer.h gnutls_auth_int.h		\
 	x509_b64.h gnutls_v2_compat.h gnutls_datum.h auth_cert.h	\
 	gnutls_mpi.h gnutls_pk.h gnutls_record.h gnutls_cert.h		\
-	gnutls_constate.h gnutls_global.h strfile.h gnutls_sig.h	\
-	gnutls_mem.h io_debug.h ext_max_record.h gnutls_session_pack.h	\
-	gnutls_str.h gnutls_state.h gnutls_x509.h ext_cert_type.h	\
+	gnutls_constate.h gnutls_global.h gnutls_sig.h gnutls_mem.h	\
+	io_debug.h ext_max_record.h gnutls_session_pack.h gnutls_str.h	\
+	gnutls_state.h gnutls_x509.h ext_cert_type.h			\
 	gnutls_rsa_export.h ext_server_name.h auth_dh_common.h		\
 	ext_srp.h gnutls_srp.h auth_srp.h auth_srp_passwd.h		\
 	gnutls_helper.h auth_psk.h auth_psk_passwd.h			\
Index: lib/gnutls_x509.c
===
RCS file: /cvs/gnutls/gnutls/lib/gnutls_x509.c,v
retrieving revision 2.174
retrieving revision 2.175
diff -u -r2.174 -r2.175
--- lib/gnutls_x509.c	18 Mar 2006 12:49:09 -	2.174
+++ lib/gnutls_x509.c	16 Jun 2006 13:29:36 -	2.175
@@ -48,6 +48,7 @@
 #include "x509/mpi.h"
 #include "x509/pkcs7.h"
 #include "x509/privkey.h"
+#include "read-file.h"
 
 /*
  * some x509 certificate parsing functions.
@@ -737,126 +738,6 @@
   return 0;
 }
 
-/* Opens a file reads its contents and stores it
- * in allocated memory, which is returned.
- */
-#include 
-#include 
-#include 
-#include 
-
-#ifdef HAVE_MMAP
-# include 
-# include 
-# ifndef MAP_FAILED
-#  define MAP_FAILED (void *)-1L
-# endif
-#endif
-
-#include 
-
-void
-_gnutls_strfile_free (strfile * x)
-{
-#ifdef HAVE_MMAP
-  if (x->mmaped)
-{
-  munmap (x->data, x->size);
-  return;
-}
-#endif
-
-  gnutls_free (x->data);
-  x->data = NULL;
-}
-
-strfile
-_gnutls_file_to_str (const char *file)
-{
-  int fd1 = -1;
-  struct stat stat_st;
-  size_t tot_size;
-  size_t left;
-  opaque *tmp;
-  ssize_t i = 0;
-  strfile null = { NULL, 0, 0 };
-  strfile ret = { NULL, 0, 0 };
-
-  fd1 = open (file, 0);
-  if (fd1 == -1)
-{
-  gnutls_assert ();
-  return null;
-}
-
-  if (fstat (fd1, &stat_st) == -1)
-{
-  gnutls_assert ();
-  goto error;
-}
-
-  tot_size = stat_st.st_size;
-  if (tot_size == 0)
-{
-  gnutls_assert ();
-  goto error;
-}
-#ifdef HAVE_MMAP
-  if ((tmp =
-   mmap (NULL,

Bug#402665: [Pkg-gnutls-maint] Bug#402665: STARTTLS causes segfault

2006-12-12 Thread James Westby
> On 2006-12-12 [EMAIL PROTECTED] wrote:
> > Package: exim4-daemon-heavy
> > Version: 4.63-11
> 
> > When I try to send authenticated email through my server using TLS,
> > the server crashes.

Thanks for the report. 

Unfortunately the traces you provided are not that informative. It would
be great to get some more information on the connection.

Some things that would be good to have the output of

  * Does gnutls-cli (in gnutls-bin) or openssl s_client trigger the bug.

(gnutls  -p  and openssl s_client -connect :
 will get you started, you just type in to them and it relays the
 text across the session. You can fake an SMTP session if it needs
 to get that far.)

If one/both of them do then the trace of that, and also one with -d 11
added to the command line would be useful.

  * The output of gnutls-cli-debug run against the server. (In the
libgnutls13-dbg package). The output against both a broken and fixed
version would be useful for comparison.

  * The output of swaks run against the server.

  * Do you see this problem with multiple clients? Which ones?

  * Do you have anything strange in the setup? Could I have your config
if there is nothing private in it so that I can set up test server
to beat up?

Thanks,

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: [Pkg-gnutls-maint] Bug#402665: STARTTLS causes segfault

2006-12-12 Thread Peter Chubb
> "James" == James Westby <[EMAIL PROTECTED]> writes:


James> Unfortunately the traces you provided are not that
James> informative. It would be great to get some more information on
James> the connection.


It was:
telnet mx.chubb.wattle.id.au 25
ehlo croc
starttls
and the server died.  It *should* return 220 TLS go ahead.  It's dying
*before* the TLS handshake starts.


I tried to reproduce the bug (reinstalled 1.4.4-3) and the problem has
stopped occurring.  I *hate* bugs like that.


James>   * Do you have anything strange in the setup? Could I have
James> your config if there is nothing private in it so that I can set
James> up test server to beat up?

The setup is a standard Debian system, with sa_exim and
exim-daemon-heavy, with the parts in
conf.d/auth/30_exim4-config_examples uncommented to allow AUTH PLAIN
and AUTH LOGIN. 

I'd rather the config wasn't kept on a website forever, so I'll put it
up at http://gelato.unsw.edu.au/~peterc/exim4-conf.tar.bz2; let me
know when you've fetched it.

Other info:  the failing site is a virtual x86 machine under Xen, but
this shouldn't make any difference.

The libgnutls13 package that works is 1.4.2-1 

dpkg -l libgnutls13
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  libgnutls131.4.2-1the GNU TLS library - runtime library


--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au   ERTOS within National ICT Australia


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: [Pkg-gnutls-maint] Bug#402665: STARTTLS causes segfault

2006-12-12 Thread James Westby
On (13/12/06 09:56), Peter Chubb wrote:
> > "James" == James Westby <[EMAIL PROTECTED]> writes:
> 
> 
> James> Unfortunately the traces you provided are not that
> James> informative. It would be great to get some more information on
> James> the connection.
> 
> 
> It was:
>   telnet mx.chubb.wattle.id.au 25
>   ehlo croc
>   starttls
> and the server died.  It *should* return 220 TLS go ahead.  It's dying
> *before* the TLS handshake starts.

Ah, OK, I see that now, thanks for the clarification.

I haven't had time for a full research, but from a quick look at the
code the next big things it does after 

  initializing GnuTLS as a server

is printed in the log is initialise GnuTLS (surprise, surprise),
specifically it calls 

  gnutls_global_init
  init_dh

The first of these is a GnuTLS function, and it is called by every API
client on every setup, so if it was severely broken then we would
probably know about it by now (I'm not ruling out it being broken
though). The second is an exim gnutls related function that sets up the
DH parameters for the session, or reads them from a file.

The strace output shows /dev/urandom being read which I believe will be
done in the init function (I haven't confirmed yet though) and then exim
dying shortly afterwards.

I shall try and do some more digging in to the code tomorrow, and try
and set up an instance of exim to test this.

> 
> I tried to reproduce the bug (reinstalled 1.4.4-3) and the problem has
> stopped occurring.  I *hate* bugs like that.

Me too. 

Hopefully it will stay this way. You could see if there is anything in
the output of 

  which-pkg-broke exim4
  or
  which-pkg-broke libgnutls13

(which-pkg-broke is in the debian-goodies package). 

If the server is not critical I would appreciate it if you would keep
the buggy version installed and follow up here if the problem reoccurs.

> 
> James>   * Do you have anything strange in the setup? Could I have
> James> your config if there is nothing private in it so that I can set
> James> up test server to beat up?
> 
> The setup is a standard Debian system, with sa_exim and
> exim-daemon-heavy, with the parts in
> conf.d/auth/30_exim4-config_examples uncommented to allow AUTH PLAIN
> and AUTH LOGIN. 
> 
> I'd rather the config wasn't kept on a website forever, so I'll put it
> up at http://gelato.unsw.edu.au/~peterc/exim4-conf.tar.bz2; let me
> know when you've fetched it.

Thanks, I've got it. I'll try and use it soon.

> 
> Other info:  the failing site is a virtual x86 machine under Xen, but
> this shouldn't make any difference.

Yes, it shouldn't. People do have entropy problems without special libc6
packages under Xen, but that shouldn't be causing any segfaults.

> 
> The libgnutls13 package that works is 1.4.2-1 
> 

Ok, thanks,

I'll see if I can bring myself to read the diff between these two
versions.

Thanks,

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: [Pkg-gnutls-maint] Bug#402665: STARTTLS causes segfault

2006-12-15 Thread Steve Langasek
severity 402665 important
tags 492665 moreinfo unreproducible
thanks

On Wed, Dec 13, 2006 at 09:56:51AM +1100, Peter Chubb wrote:
> I tried to reproduce the bug (reinstalled 1.4.4-3) and the problem has
> stopped occurring.  I *hate* bugs like that.

:)

Based on this, I'd say the bug should be downgraded pending a reproducible
test case.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#402665: [Pkg-gnutls-maint] Bug#402665: STARTTLS causes segfault

2007-02-02 Thread William Boughton

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
+
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  0x2b4a8c20e748 in memmem () from /lib/libc.so.6
(gdb) bt
#0  0x2b4a8c20e748 in memmem () from /lib/libc.so.6
#1  0x2b4a8c402f34 in _gnutls_fbase64_decode ()
   from /usr/lib/libgnutls.so.13
#2  0x2b4a8c4271e7 in gnutls_x509_crt_import ()
   from /usr/lib/libgnutls.so.13
#3  0x2b4a8c412e7f in gnutls_certificate_set_x509_crl_mem ()
   from /usr/lib/libgnutls.so.13
#4  0x2b4a8c4141ad in gnutls_certificate_set_x509_trust_file ()
   from /usr/lib/libgnutls.so.13
#5  0x0046b2fb 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  0x0046c2fc in tls_server_start (require_ciphers=0x0)
at tls-gnu.c:773
#7  0x00461f3b in smtp_setup_msg () at smtp_in.c:3497
#8  0x00430536 in main (argc=3, cargv=)
at exim.c:4380

ii  libgnutls131.4.4-3the 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.0 +
+++ /tmp/b  2007-02-02 17:24:37.0 +
@@ -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  0x2b941e51b748 in memmem () from /lib/libc.so.6
(gdb) bt
#0  0x2b941e51b748 in memmem () from /lib/libc.so.6
#1  0x2b941dca7f34 in _gnutls_fbase64_decode ()
   from /usr/lib/libgnutls.so.13
#2  0x2b941dccc1e7 in gnutls_x509_crt_import ()
   from /usr/lib/libgnutls.so.13
#3  0x2b941dcb7e7f in gnutls_certificate_set_x509_crl_mem ()
   from /usr/lib/libgnutls.so.13
#4  0x2b941dcb91ad in gnutls_certificate_set_x509_trust_file ()
   from /usr/lib/libgnutls.so.13
#5  0x00406e48 in ?? ()
#6  0x2b941e4c34ca in __libc_start_main () from /lib/libc.so.6
#7  0x00403fca in ?? ()
#8  0x7fe893e8 in ?? ()
#9  0x 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]