Bug 8280 - Our GnuTLS is out of date
Summary: Our GnuTLS is out of date
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.16.0
Assignee: Adam Halim
URL:
Keywords: frifl_tester, linma_tester, relnotes
Depends on:
Blocks:
 
Reported: 2024-01-02 16:43 CET by Adam Halim
Modified: 2024-01-08 14:32 CET (History)
3 users (show)

See Also:
Acceptance Criteria:
MUST: * GnuTLS included in ThinLinc should not have any known security issues affecting ThinLinc users SHOULD: * The latest stable GnuTLS should be included in ThinLinc EXTRA: * GnuTLS and its dependencies should be updated to their latest versions (nettle, libtasn1 and gmp)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Adam Halim cendio 2024-01-02 16:43:16 CET 
We currently have GnuTLS 3.6.16 in our build system. The latest stable version is 3.8.2, and there have been some security fixes since our last upgrade.

The following fixes have been listed:

* CVE-2023-5981, CVE-2023-0361
  Affects us as we support RSA and RSA-PSK. Both CVEs are side-channel attacks
  with moderate severity.

* CVE-2022-2509, GNUTLS-SA-2022-01-17
  As far I can tell, we don't use the affected functions
  (gnutls_pkcs7_verify() and gnutls_x509_trust_list_verify_crt2()).
  
* CVE-2021-20231, CVE-2021-20232
  The "key_share" and "pre_shared_key" extensions are used as part of the TLS
  handshake, GnuTLS considers it low-risk and low impact.
Comment 4 Adam Halim cendio 2024-01-03 15:49:16 CET 
For CVE-2023-0361 [1] and CVE-2023-5981 [2], it is possible to exploit a web server by using a client which uses RSA for the key exchange. It seems like this is a difficult attack to exploit in practice, especially over the internet, as it is timing-sensitive. The consequence of a successful attack is getting the server's private key.

By default, all modern browsers won't use RSA during the key exchange, but it is still possible to modify a browser to force the server to use RSA (as it is enabled by default when using gnutls_priority=NORMAL). I could easily do this in Firefox 121.

I think it is possible to mitigate these vulnerabilities by disabling RSA completely from the server side. For me, it was enough to set /tlwebadm/gnutls_priority and /webaccess/gnutls_priority to "NORMAL:-RSA:-DHE-RSA:-ECDHE-RSA" (using GnuTLS 3.8.2). Connecting to the server with my modified Firefox gave a "Secure Connection Failed" error, and the following in tlwebadm.log:
> 2024-01-03 15:47:41 ERROR tlwebadm[22827]: [::ffff:10.47.1.80] gnutls_handshake: No supported cipher suites have been found.
Further reading:
[1] https://gitlab.com/gnutls/gnutls/-/issues/1050
[2] https://gitlab.com/gnutls/gnutls/-/issues/1511
[3] https://en.wikipedia.org/wiki/Timing_attack
[4] https://paulkocher.com/doc/TimingAttacks.pdf
[5] http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
[6] https://gnutls.org/manual/html_node/Priority-Strings.html
Comment 7 Adam Halim cendio 2024-01-03 16:04:20 CET 
It is worth mentioning that the SRP protocol is disabled by default since GnuTLS 3.8.0 due to it not being up-to-date with current standards. As far as I can tell, there are no browsers today with SRP support, so hopefully nobody is affected by this.
Comment 8 Adam Halim cendio 2024-01-03 16:06:33 CET 
Tested the following without any issues:

tlwebadm from the following browsers:
  Firefox       120
  Chrome        120
  Edge          120
  Safari macOS  17.1
  Safari iOS    15.7.8

Web access with the following browsers:
  Firefox       120
  Chrome        120
  Edge          120
  Safari        17.1
  Safari iOS    15.7.8

Tested /tlwebadm/gnutls_priority with SECURE256 and could see that
TLS_CHACHA20_POLY1305_SHA256 was used.
Comment 11 Frida Flodin cendio 2024-01-08 13:23:24 CET 
Tested on iPhone and Mac Mini x86 and everything works fine:
✅ WebAccess using Safari on iOS 17.2.1
✅ Webadmin using Safari on iOS 17.2.1

✅ WebAccess using Safari on macOS 14.2.1
✅ Webadmin using Safari on macOS 14.2.1
✅ WebAccess using Chrome 120.0.6099 on macOS 14.2.1
✅ Webadmin using Chrome 120.0.6099 on macOS 14.2.1
Comment 12 Linn cendio 2024-01-08 13:46:09 CET 
Tested on Windows 10 and Android 13 against Jenkins build 3473 on Ubuntu 20.04. Everything works fine.

✅ WebAccess and Webadmin using Chrome v. 120 on Android 13
✅ WebAccess and Webadmin using Firefox v. 121 on Android 13
✅ WebAccess and Webadmin using Edge v. 120 on Android 13

✅ WebAccess and Webadmin using Chrome v. 120 on Windows 10
✅ WebAccess and Webadmin using Firefox v. 121 on Windows 10
✅ WebAccess and Webadmin using Edge v. 120 on Windows 10

With that, this bug is fully tested, closing.
Comment 13 Linn cendio 2024-01-08 14:32:36 CET 
Forgot to mention, but I also checked release notes, the commits and that I got the newer packages when updating cendio-build packages. Everything looked good.
Note You need to log in before you can comment on or make changes to this bug.