Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)
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 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=0x55db4350) at ../tls/gnutls/gtlsconnection-gnutls.c:1907
#1 handshake_thread (task=0x7fffd800e2a0, object=0x55db4350,
task_data=, cancellable=) at
../tls/gnutls/gtlsconnection-gnutls.c:1907
#2 0x73818343 in g_task_thread_pool_thread
(thread_data=0x7fffd800e2a0, pool_data=) at
../../../gio/gtask.c:1331
#3 0x73676db3 in g_thread_pool_thread_proxy (data=) at
../../../glib/gthreadpool.c:307
#4 0x73676415 in g_thread_proxy (data=0x55dea990) at
../../../glib/gthread.c:784
#5 0x73374fa3 in start_thread (arg=) at
pthread_create.c:486
#6 0x732a54cf 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
Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)
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.
Please mark glib-networking 2.64.3-2 as breaking Balsa versions 2.5.7
through 2.6.0. If you only care about versions of balsa that are
currently in any release of debian, that would be just:
Breaks: balsa (= 2.6.0-2)
Hope this helps!
Regards,
--dkg
signature.asc
Description: PGP signature
Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)
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. smcv
Bug#961792: balsa: needs to set expected server identity (for CVE-2020-13645)
Package: balsa Version: 2.4.12-1 Severity: important Tags: security Control: block 961756 by -1 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). I've reported this against the oldoldstable version, in the hope that that will help the LTS people to avoid regressing balsa by updating glib-networking too soon. I believe the minimal change is to apply e8952e3c "fix NULL server-identity TLS warning with recent gio", but I don't know or use balsa. 0ae0fde1 "Improve TLS certificate validation error message" would probably also be a good idea. Those are new in 2.6.1, and are not present in 2.6.0. For testing/unstable, please update to 2.6.1 which fixes this. For stable and oldstable, I think backporting will be necessary. smcv
