Bug#638595: WWWOFFLE HTTPS now unusable

[Andrew M. Bishop]

amb at gedanken.demon.co.uk (Andrew M. Bishop) writes:

> This is with a vanilla wwwoffle 2.9g - unmodified since released.

> Looking at the list of functions I can see that there are two
> gnutls_x509_*_deinit() functions called before the handshake.
>
> Calling the first one, gnutls_x509_crt_deinit(), is OK, but calling
> the second one, gnutls_x509_privkey_deinit(), before the handshake
> will cause it to crash.
>
> The documentation for these functions don't say that you can't call
> the 'deinit' function until after the handshake.  The libgnutls NEWS
> file doesn't say that there is an ABI change in this area either.  It
> certainly used to work that you could do this.

Testing again on a system that calls itself "Debian GNU/Linux 4.0" and
that uses gnutls version 1.4.4-3+etch5 shows that WWWOFFLE doesn't
crash.


One other, probably unrelated, point that I came across while
debugging the problem is that libgnutls and its dependencies raise
some errors when run under valgrind.  Here for example is just part of
the sequence of errors that come from the gnutls example server code.

$ valgrind ./test-server
==18562== Memcheck, a memory error detector
==18562== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==18562== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==18562== Command: ./test-server
==18562== 
==18562== Invalid read of size 4
==18562==    at 0x4263758: asn1_der_coding (in /usr/lib/i386-linux-gnu/libtasn1.so.3.1.11)
==18562==    by 0x4095F09: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x4097133: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x40BAF3B: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x4075AD3: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x407767F: gnutls_certificate_set_x509_trust_file (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x8048EB3: main (in /home/amb/temp/gnutls/test-server)
==18562==  Address 0x4350a2c is 20 bytes inside a block of size 23 alloc'd
==18562==    at 0x4025018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18562==    by 0x426373B: asn1_der_coding (in /usr/lib/i386-linux-gnu/libtasn1.so.3.1.11)
==18562==    by 0x4095F09: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x4097133: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x40BAF3B: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x4075AD3: ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x407767F: gnutls_certificate_set_x509_trust_file (in /usr/lib/i386-linux-gnu/libgnutls.so.26.21.1)
==18562==    by 0x8048EB3: main (in /home/amb/temp/gnutls/test-server)

I am not saying that this is a security problem, but it is clear that
the code is reading beyond the end of a block of allocated memory.
The allocated memory is probably rounded up to a multiple of 4 or 8
bytes for alignment purposes by the memory allocator so this would be
OK in reality.

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop                             amb at gedanken.demon.co.uk
                                      http://www.gedanken.demon.co.uk/

WWWOFFLE users page:
        http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html