Bug#1064551: bookworm-pu: libjwt/1.10.2-1+deb11u1

2024-03-02 Thread Thorsten Alteholz




On Sun, 25 Feb 2024, Jonathan Wiltshire wrote:

Please go ahead.


great, thanks ...

... and uploaded.


 Thorsten



Bug#1064551: bookworm-pu: libjwt/1.10.2-1+deb11u1

2024-02-25 Thread Jonathan Wiltshire
Control: tag -1 confirmed

On Sat, Feb 24, 2024 at 12:50:51AM +, Thorsten Alteholz wrote:
> The attached debdiff for libjwt fixes
> CVE-2024-25189 in Bookworm. It is marked as
> no-dsa by the security team.
> The fix is straightfoward and should not make any problems.

It seems quite a lot of effort for something even the author thinks is
infeasible in the real world, but OK. Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1



Bug#1064551: bookworm-pu: libjwt/1.10.2-1+deb11u1

2024-02-23 Thread Thorsten Alteholz

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for libjwt fixes CVE-2024-25189 in Bookworm. It is 
marked as no-dsa by the security team.

The fix is straightfoward and should not make any problems.

  Thorsten
diff -Nru libjwt-1.10.2/debian/changelog libjwt-1.10.2/debian/changelog
--- libjwt-1.10.2/debian/changelog  2019-07-14 19:03:00.0 +0200
+++ libjwt-1.10.2/debian/changelog  2024-02-19 22:03:02.0 +0100
@@ -1,3 +1,10 @@
+libjwt (1.10.2-1+deb12u1) bookworm; urgency=medium
+
+  * CVE-2024-25189 (Closes: #1063534)
+fix a timing side channel via strcmp()
+
+ -- Thorsten Alteholz   Mon, 19 Feb 2024 22:03:02 +0100
+
 libjwt (1.10.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libjwt-1.10.2/debian/libjwt0.symbols 
libjwt-1.10.2/debian/libjwt0.symbols
--- libjwt-1.10.2/debian/libjwt0.symbols2019-01-13 15:13:51.0 
+0100
+++ libjwt-1.10.2/debian/libjwt0.symbols2024-02-19 22:03:02.0 
+0100
@@ -38,5 +38,6 @@
  jwt_sign_sha_hmac@Base 1.9.0
  jwt_sign_sha_pem@Base 1.9.0
  jwt_str_alg@Base 1.9.0
+ jwt_strcmp@Base 1.10.2
  jwt_verify_sha_hmac@Base 1.9.0
  jwt_verify_sha_pem@Base 1.9.0
diff -Nru libjwt-1.10.2/debian/libjwt-gnutls0.symbols 
libjwt-1.10.2/debian/libjwt-gnutls0.symbols
--- libjwt-1.10.2/debian/libjwt-gnutls0.symbols 2019-01-13 15:13:51.0 
+0100
+++ libjwt-1.10.2/debian/libjwt-gnutls0.symbols 2024-02-19 22:03:02.0 
+0100
@@ -38,5 +38,6 @@
  jwt_sign_sha_hmac@Base 1.9.0
  jwt_sign_sha_pem@Base 1.9.0
  jwt_str_alg@Base 1.9.0
+ jwt_strcmp@Base 1.10.2
  jwt_verify_sha_hmac@Base 1.9.0
  jwt_verify_sha_pem@Base 1.9.0
diff -Nru libjwt-1.10.2/debian/patches/CVE-2024-25189-1.patch 
libjwt-1.10.2/debian/patches/CVE-2024-25189-1.patch
--- libjwt-1.10.2/debian/patches/CVE-2024-25189-1.patch 1970-01-01 
01:00:00.0 +0100
+++ libjwt-1.10.2/debian/patches/CVE-2024-25189-1.patch 2024-02-19 
22:03:02.0 +0100
@@ -0,0 +1,130 @@
+commit f73bac57c5bece16ac24f1a70022aa34355fc1bf
+Author: Ben Collins 
+Date:   Fri Feb 9 09:03:35 2024 -0500
+
+Implement a safer strcmp() function
+
+As noted, the strcmp() function can be used for time-based side attacks.
+
+I tried to test this and could not find a reasonable way to implement
+this attack for several reasons:
+
+1) strcmp() is optimized to compare 4 and 8 bytes at a time when possible
+   on almost every modern system, making the attack almost impossible.
+2) Running 128 million iterations of strcmp() for a single byte attack
+   gave sub-nanosecond average differences (locally on same excution stack)
+   and almost as often as the comparison was correct, it was also wrong in
+   the reverse sense (i.e. two byte strcmp() took less time than single
+   byte).
+3) Adding noise from network, application stack, web server, etc. would
+   only add to the failure rate of guessing the differences above.
+
+Erwan noted that there are proofs out there showing that signal noise
+reduction can make this guessing more "accurate", but this proof also
+noted it would take up to 4 billion guesses to completely cover this
+attack surface. The claim was that 50k attempts per second would break
+a 256-bit hmac in 22 hours. While this isn't impossible, it's very
+implausible.
+
+However, for the sake of cryptographic correctness, I implemented
+jwt_strcmp() which always compares all bytes, and does so up to the
+longest string in the 2-string set, without passing string boundaries.
+
+This makes it time-consistent for len(max(a,b)) comparisons. I proofed
+this using a 128 million interation average for various scenarious.
+
+Reported-by: Erwan Legrand 
+Signed-off-by: Ben Collins 
+
+Index: libjwt-1.10.2/libjwt/jwt-gnutls.c
+===
+--- libjwt-1.10.2.orig/libjwt/jwt-gnutls.c 2024-02-19 22:38:58.575655983 
+0100
 libjwt-1.10.2/libjwt/jwt-gnutls.c  2024-02-19 22:38:58.571655984 +0100
+@@ -90,7 +90,7 @@
+   jwt_Base64encode(buf, sig_check, len);
+   jwt_base64uri_encode(buf);
+ 
+-  if (!strcmp(sig, buf))
++  if (!jwt_strcmp(sig, buf))
+   ret = 0;
+ 
+   free(sig_check);
+Index: libjwt-1.10.2/libjwt/jwt-openssl.c
+===
+--- libjwt-1.10.2.orig/libjwt/jwt-openssl.c2024-02-19 22:38:58.575655983 
+0100
 libjwt-1.10.2/libjwt/jwt-openssl.c 2024-02-19 22:38:58.571655984 +0100
+@@ -140,7 +140,7 @@
+   jwt_base64uri_encode(buf);
+ 
+   /* And now... */
+-  ret = strcmp(buf, sig) ? EINVAL : 0;
++  ret = jwt_strcmp(buf, sig) ? EINVAL : 0;
+ 
+ jwt_verify_hmac_done:
+   BIO_free_all(b64);
+Index: libjwt-1.10.2/libjwt/jwt-private.h