Bug 15103 (CVE-2022-1615) - CVE-2022-1615 [SECURITY] GnuTLS gnutls_rnd() can fail and give predictable random values
Summary: CVE-2022-1615 [SECURITY] GnuTLS gnutls_rnd() can fail and give predictable ra...
Status: NEW
Alias: CVE-2022-1615
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.16.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-21 22:38 UTC by Andrew Bartlett
Modified: 2022-11-01 19:18 UTC (History)
4 users (show)

See Also:


Attachments
patch to turn gnutls_rnd failure into smb_panic (1.37 KB, patch)
2022-06-21 22:42 UTC, Douglas Bagnall
no flags Details
v2 patch with amended message, fixes generate_nonce_buffer() (1.82 KB, patch)
2022-06-22 22:24 UTC, Douglas Bagnall
no flags Details
v3 patch, includes gnutls errno and strerror, compilation deps (2.64 KB, patch)
2022-06-23 02:51 UTC, Douglas Bagnall
asn: review+
Details
Backport patch for 4.15 (2.91 KB, patch)
2022-11-01 19:18 UTC, David Mulder
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bartlett 2022-06-21 22:38:57 UTC
Found because the Samba AD DC would not provision due to a duplicate GUID error on LMDB when we updated our docker image for Fedora 36 FIPS build.

https://gitlab.com/samba-team/devel/samba/-/jobs/2614337241

Evidence:

Getting into this with a debugger shows the provision looping attempting to make the not-random buffer pass our password quality check. 

generate_secret_buffer (out=0x563af6a0de30 'D' <repeats 188 times>, len=188) at ../../lib/util/genrand.c:52
#1  0x00007f88f0b2b743 in generate_random_str_list (mem_ctx=0x0, len=188, list=0x7f88f0b7f798 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+_-#.,@$%&!?:;<=>()[]~")
    at ../../lib/util/genrand_util.c:209
#2  0x00007f88f0b2b8c5 in generate_random_password (mem_ctx=0x0, min=128, max=255) at ../../lib/util/genrand_util.c:279
#3  0x00007f88edcb9343 in py_generate_random_password (self=0x7f88f0d6dbc0, args=0x7f88ec360800) at ../../python/pyglue.c:57


This shows the deterministic secret:
#1  0x00007f88f0b2b743 in generate_random_str_list (mem_ctx=0x0, len=188, list=0x7f88f0b7f798 "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+_-#.,@$%&!?:;<=>()[]~")
    at ../../lib/util/genrand_util.c:209
209		generate_secret_buffer((uint8_t *)retstr, len);
(gdb) p retstr
$8 = 0x563af6a0de30 'j' <repeats 188 times>


This shows the failure:
Breakpoint 4, gnutls_rnd (level=GNUTLS_RND_KEY, data=0x563af6a0de30, len=188) at random.c:167
167	{
(gdb) finish
Run till exit from #0  gnutls_rnd (level=GNUTLS_RND_KEY, data=0x563af6a0de30, len=188) at random.c:167
generate_secret_buffer (out=0x563af6a0de30 'D' <repeats 188 times>, len=188) at ../../lib/util/genrand.c:52
52	}
Value returned is $9 = -402
Comment 1 Douglas Bagnall 2022-06-21 22:42:56 UTC
Created attachment 17386 [details]
patch to turn gnutls_rnd failure into smb_panic

This is a patch I wrote and ignored in 2019, that turns an RNG failure into an smb_panic.

I don't remember why I forgot it. Perhaps I thought we should pass the error up, but at the end of the chain, what else can we do?
Comment 2 Andreas Schneider 2022-06-22 06:46:15 UTC
The patch looks fine for me, I would just improve the error message:

smb_panic("GnuTLS could not generate a random buffer");
Comment 3 Douglas Bagnall 2022-06-22 22:24:59 UTC
Created attachment 17389 [details]
v2 patch with amended message, fixes generate_nonce_buffer()

The old patch also ignored generate_nonce_buffer(), which perhaps didn't exist then.


The questions I wonder about, regarding severity, are:

1. can we know it is only recent Fedora in FIPS mode that is affected?

2. is it practically possible that Samba will run with repeated deterministic secrets? I mean, we see that provision fails, but what happens with an in-place upgrade?
Comment 4 Andrew Bartlett 2022-06-22 22:42:16 UTC
The in-place risk is real, Fedora 36 was working, and now fails.

The biggest risk is to NTLM challenge/response because it would allow replay of observed challenges, but also the fortnightly password change might select a weak password.

The 'password quality' checks that happen in the AD DC provision don't apply to the winbindd password change in generate_random_machine_password(), so the impact would be silent and catastrophic for security (allow forging of incoming Kerberos tickets).
Comment 5 Andrew Bartlett 2022-06-22 23:08:01 UTC
We should print the GnuTLS error, numerically and via gnutls_strerror_name(), so folks have a hope of working out why.

For reference the -402 we got is 
GNUTLS_E_LIB_IN_ERROR_STATE
Comment 6 Andrew Bartlett 2022-06-23 01:44:15 UTC
(In reply to Andrew Bartlett from comment #4)
My comment was not clear (I realised the second point after writing the first). 

The in-place risk is real, Fedora 36 was working, and now fails.

One risk is to NTLM challenge/response because it would allow replay of observed challenges, but also the fortnightly password change might select a weak password.

However the biggest risk is that the winbindd password change in generate_random_machine_password() could return a weak password.

The impact would be silent and catastrophic for security (allow forging of incoming Kerberos tickets).
Comment 7 Douglas Bagnall 2022-06-23 02:51:18 UTC
Created attachment 17390 [details]
v3 patch, includes gnutls errno and strerror, compilation deps
Comment 8 Andreas Schneider 2022-06-23 08:07:53 UTC
The questions is why on quay.io images it fails the gnutls fips selfcheck.
Comment 9 Andreas Schneider 2022-06-23 09:21:07 UTC
The CI runner failed, because the gnutls selfcheck failed.

gnutls[2]: Calculated MAC for /lib64/libnettle.so.8 does not match

If the selfcheck fails the library is non working. You wont be able to do any crypto operations, they would just all fail. As we did not check the return value of the rand function, we did not catch it when created random buffers.

However the rest of Samba should just not work in this case.
Comment 10 Andrew Bartlett 2022-06-28 07:25:56 UTC
(In reply to Andreas Schneider from comment #9)
Is there any other way, in a different situation, where only the RNG could fail?

If so, this needs to be pushed out as a security release, ideally.  Do you have the time to run that process?

Otherwise if an RNG-only failure is unlikely outside FIPS mode and so we just think this is too niche (FIPS use is rare, presumably) we could just un-embargo and move on, possible with a CVE assigned.

What do you want to do?
Comment 11 Andreas Schneider 2022-06-28 13:52:15 UTC
I've discussed it with Huzaifa and we do not think it is very serious or security hardening. On modern Linux this uses either getentropy() or getrandom(). If those fails you have a serious problem on your system.

The issue we see is becaus of the failing FIPS selfcheck of GnuTLS, but that means GnuTLS wont work at all. Every function would return an error.

I'm for getting a CVE and just fixing it. Put it in git and it will be released with the next security or maintenance update.
Comment 12 Stefan Metzmacher 2022-07-22 12:26:46 UTC
Comment on attachment 17390 [details]
v3 patch, includes gnutls errno and strerror, compilation deps

> 
>+
>+ _NORETURN_ static void genrand_panic(int err)

This should also get __func__ and __location__

>+{
>+	char buf[200];
>+	snprintf(buf, sizeof(buf),
>+		 "GnuTLS could not generate a random buffer: %s [%d]\n",
>+		 gnutls_strerror_name(err), err);
>+	smb_panic(buf);
>+}
Comment 13 Douglas Bagnall 2022-07-26 02:00:42 UTC
(In reply to Stefan Metzmacher from comment #12)
Thanks Metze,

If nobody disagrees with the Andreas/Huzaifa security assessment, I will make a gitlab MR with that change in a day or two.
Comment 14 Douglas Bagnall 2022-07-28 00:00:25 UTC
https://gitlab.com/samba-team/samba/-/merge_requests/2644

I realised halfway through that I forgot the "get a CVE" part of "get a CVE and release it anyway". So too bad there.
Comment 15 Douglas Bagnall 2022-07-28 00:02:06 UTC
(In reply to Douglas Bagnall from comment #14)
> So too bad there.

Well, we could still do that of course.
Comment 16 Andrew Bartlett 2022-07-28 05:11:20 UTC
CVE-2022-1615 was allocated to us in the past and RH didn't reply when we tried to return it, so lets just use it instead.
Comment 17 Samba QA Contact 2022-07-28 06:19:03 UTC
This bug was referenced in samba master:

9849e7440e30853c61a80ce1f11b7b244ed766fe
Comment 18 Samba QA Contact 2022-08-08 14:32:39 UTC
This bug was referenced in samba v4-17-test:

9849e7440e30853c61a80ce1f11b7b244ed766fe
Comment 19 Samba QA Contact 2022-08-08 14:36:19 UTC
This bug was referenced in samba v4-17-stable (Release samba-4.17.0rc1):

9849e7440e30853c61a80ce1f11b7b244ed766fe
Comment 20 Stefan Metzmacher 2022-09-06 08:25:43 UTC
(In reply to Samba QA Contact from comment #19)

Andreas, do you want to backport this, or should we close the bug report?
Comment 21 Andrew Bartlett 2022-10-29 08:01:20 UTC
Once we work out https://gitlab.com/samba-team/samba/-/merge_requests/2778 which will need its own bug, we should backport this to 4.16 and 4.15 also, as we have good reason to think this can fail 'in the wild'.
Comment 22 David Mulder 2022-11-01 19:18:23 UTC
Created attachment 17609 [details]
Backport patch for 4.15

SUSE backported this patch a couple months ago. Sorry for failing to mention this before.