www.cendio.com
Bug 6038 - Upgrade GnuTLS to latest version
: Upgrade GnuTLS to latest version
Status: CLOSED FIXED
: ThinLinc
Build system
: trunk
: PC Unknown
: P2 Normal
: 4.8.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2016-10-05 09:59 by
Modified: 2017-03-24 10:54 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2016-10-05 09:59:41
using 3.5.1, latest is 3.5.4. As far as I can tell from
http://www.gnutls.org/security.html, there are no critical bugs affecting us.
------- Comment #1 From cendio 2016-11-10 08:56:25 -------
Updating to 3.5.6 which are a bugfix release just like 3.5.5.
------- Comment #3 From cendio 2016-11-18 10:31:57 -------
tlwebaccess and tlwebadm work fine with both Firefox and Chrome. The generated
GnuTLS appendix in the TAG also look fine.

> The connection to this site is encrypted and authenticated using
> a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA),
> and a strong cipher (AES_128_GCM).
------- Comment #4 From cendio 2016-12-02 12:25:58 -------
I can't connect to tlwebadm/tlwebaccess in nightly builds.

tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal,
Description: Unexpected Message)" to a ClientHello msg.

Browsers report this as:
> This site can’t be reached
> localhost unexpectedly closed the connection.
> ERR_CONNECTION_CLOSED
------- Comment #6 From cendio 2016-12-02 17:02:51 -------
Urgh. This was a fun one.

This is caused by a lovely quirk in libc. It has stubs for most pthread
functions that just return success. If the real libpthread is pulled in then
those stubs are replaced by the real thing.

This can easily go south if this happens after a while, rather than when the
process is started. A mutex you initialised with the stub routines is a poor
fit for the real pthread_mutex_lock().

And this is precisely what happened here. pthread_mutex_lock() returned an
error on the bogus mutex, and GnuTLS called abort() when it couldn't grab the
mutex.

The fix is to always link to libpthread when using pthread functions. Upstream
has also gotten this wrong, so I filed a bug there:

https://gitlab.com/gnutls/gnutls/issues/154


This issue is old and should theoretically be happening on most versions of
ThinLinc. However we seem to be getting lucky and getting zeroed out memory
from malloc() when initialising these early mutexes. And as it happens, glibc's
implementation of pthread_mutex_init() also results in a zeroed out structure.
So these mutexes work despite only the stubs being loaded.

The new version of GnuTLS is causing some reordering of calls, and we're not
getting clean memory from malloc() anymore. Hence things are now crashing
instead.
------- Comment #12 From cendio 2016-12-06 14:54:50 -------
Should be all done now. 

The new tests found three components for which we didn't properly link to
libpthread; tlstunnel, mesa, and opensc. Whereof tlstunnel was the only one
where we observed an actual problem (comment #4), however all these three
components have been fixed now.

The tests pass and I have verified that tlwebaccess and tlwebadm works with
build 5310.
------- Comment #13 From cendio 2016-12-07 08:13:42 -------
The tests for linkage of pthread added in commit r31918, does no run with 
success at nightly build.
------- Comment #14 From cendio 2016-12-07 08:32:05 -------
(In reply to comment #4)
> I can't connect to tlwebadm/tlwebaccess in nightly builds.
> 
> tlstunnel responds with a "TLSv1.2 Record Layer: Alert (Level: Fatal,
> Description: Unexpected Message)" to a ClientHello msg.
> 
> Browsers report this as:
> > This site can’t be reached
> > localhost unexpectedly closed the connection.
> > ERR_CONNECTION_CLOSED

Verified that tlwebadm and tlwebacces works as expected using ThinLinc build
5312
------- Comment #17 From cendio 2016-12-07 08:41:21 -------
The new test for correct linkage and the fixes for few comoponents looks good.
Closing.