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
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?
The patch looks fine for me, I would just improve the error message: smb_panic("GnuTLS could not generate a random buffer");
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?
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).
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
(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).
Created attachment 17390 [details] v3 patch, includes gnutls errno and strerror, compilation deps
The questions is why on quay.io images it fails the gnutls fips selfcheck.
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.
(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?
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 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); >+}
(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.
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.
(In reply to Douglas Bagnall from comment #14) > So too bad there. Well, we could still do that of course.
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.
This bug was referenced in samba master: 9849e7440e30853c61a80ce1f11b7b244ed766fe
This bug was referenced in samba v4-17-test: 9849e7440e30853c61a80ce1f11b7b244ed766fe
This bug was referenced in samba v4-17-stable (Release samba-4.17.0rc1): 9849e7440e30853c61a80ce1f11b7b244ed766fe
(In reply to Samba QA Contact from comment #19) Andreas, do you want to backport this, or should we close the bug report?
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'.
Created attachment 17609 [details] Backport patch for 4.15 SUSE backported this patch a couple months ago. Sorry for failing to mention this before.
Those old versions will not receive a backort anymore. Closing now. Hope that's okay for everyone.
(In reply to Björn Jacke from comment #23) Thanks, and to clarify for history, the 'in the wild' mentioned in comment #21 turned out only to be when other patches were backported, closing the random FD. That is why https://gitlab.com/samba-team/samba/-/merge_requests/2778 never got merged, as really we needed a broader MR that was more selective in what reinit_after_fork() did, not this narrow patch.