Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)

[Emilio Pozuelo Monfort]

Control: notfound -1 2.4.12-1
Control: found -1 2.5.6-2

On Fri, 03 Jul 2020 18:26:30 -0400 Daniel Kahn Gillmor <dkg at debian.org> wrote:
> Version: 2.6.1-1
> Control: notfound 961792 2.5.6-2
> Control: notfound 961792 2.4.12-3+b1
> 
> On Thu 2020-06-25 10:18:54 +0100, Simon McVittie wrote:
> > On Fri, 29 May 2020 at 11:24:06 +0100, Simon McVittie wrote:
> >> If I'm reading https://gitlab.gnome.org/GNOME/glib-networking/-/issues/135
> >> and related issues correctly, fixing CVE-2020-13645 in glib-networking
> >> will break SSL certificate validation in balsa, which is believed to be
> >> the only widely-used application that is vulnerable to CVE-2020-13645;
> >> the new glib-networking version "fails closed", which if I understand
> >> correctly will result in balsa failing to validate any server cert.
> >> 
> >> In each supported suite, balsa should probably be updated first, and
> >> then glib-networking (perhaps with versioned Breaks on the old balsa).
> >
> > Has anyone who uses balsa had a chance to take a look at this security
> > issue? I'd prefer not to team-upload balsa, since I don't use it myself,
> > and a balsa user would be able to test it a lot better.
> 
> I can confirm that this is a problem for Balsa 2.6.0-2: it cannot
> connect to a legitimate IMAP server with sensible TLS credentials when
> run against glib-networking 2.64.3-1 (from experimental).
> 
> I've uploaded Balsa 2.6.1-1 to unstable, which appears to resolve this
> problem.  I've also tested these Balsa versions against an IMAP service
> with a certificate mismatch -- they do not "fail open", which is good.
> 
> I took a look at the version in debian stable (buster, running balsa
> 2.5.6-2) and oldstable (stretch, running balsa 2.4.12-3+b1) -- and both
> of them correctly fail closed when confronted with a certificate
> mismatch.
> 
> It appears that older versions of Balsa actually use a (rather
> complicated) OpenSSL for the TLS connection.  See
> libbalsa/{server,libbalsa}.c for more details.  Upstream adopted
> glib-networking/gio in 2.5.7 (see upstream commit
> d964df60bbd85b00269da62b99bf2ce57ae442cc, a major internal overhaul),
> and the certificate name check failed only on that version or later.

That was true for IMAP apparently, but not for POP or SMTP. Testing SMTP
in 2.5.6-2/buster, I can verify that it calls into glib-networking's
gnutls backend:

#0  verify_peer_certificate (peer_certificate=0x7fffd800b260, gnutls=0x555555db4350) at ../tls/gnutls/gtlsconnection-gnutls.c:1907
#1  handshake_thread (task=0x7fffd800e2a0, object=0x555555db4350, task_data=<optimized out>, cancellable=<optimized out>) at ../tls/gnutls/gtlsconnection-gnutls.c:1907
#2  0x00007ffff3818343 in g_task_thread_pool_thread (thread_data=0x7fffd800e2a0, pool_data=<optimized out>) at ../../../gio/gtask.c:1331
#3  0x00007ffff3676db3 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../glib/gthreadpool.c:307
#4  0x00007ffff3676415 in g_thread_proxy (data=0x555555dea990) at ../../../glib/gthread.c:784
#5  0x00007ffff3374fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6  0x00007ffff32a54cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thus I believe we have to patch balsa in buster before we can fix the
glib-networking bug. Something like [1] should do.

Cheers,
Emilio

[1] https://launchpadlibrarian.net/485808024/balsa_2.5.6-2_2.5.6-2ubuntu0.1.diff.gz