On Fri, Aug 13, 2021 at 02:46:21PM +1000, ronnie sahlberg wrote: > On Fri, Aug 13, 2021 at 1:34 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > Hi! > > > > We should be working to eliminate any uses of insecure crypto algorithms (e.g. > > DES, ARC4, MD4, MD5) from the kernel. In particular, it should be possible to > > build a kernel for a modern system without including any such algorithms. > > > > Currently, CONFIG_CIFS is problematic because it selects all these algorithms > > (kconfig options: CONFIG_CRYPTO_LIB_DES, CONFIG_CRYPTO_LIB_ARC4, > > CONFIG_CRYPTO_MD4, CONFIG_CRYPTO_MD5). > > > > It looks like these algorithms might only be used by SMB2.0 and earlier, and the > > more modern SMB versions don't use them. Is that the case? It mostly looks > > like that, but there's one case I'm not sure about -- there's a call chain which > > appears to use ARC4 and HMAC-MD5 even with the most recent SMB version: > > > > smb311_operations.sess_setup() > > SMB2_sess_setup() > > SMB2_sess_auth_rawntlmssp_authenticate() > > build_ntlmssp_auth_blob() > > setup_ntlmv2_rsp() > > md4 and md5 are used with the NTLMSSP authentication for all dialects, > including the latest 3.1.1. That's unfortunate. Surely Microsoft knows that md4 has been severely compromised for over 25 years? And md5 for 15 years. > The only other authentication mechanism for SMB is krb5. Is the long-term plan to have everyone migrate to kerberos? Currently kerberos doesn't appear to be the default, so not many people actually use it -- right? > This means that if we build a kernel without md4/md5 then we can no > longer use NTLMSSP user/password > style authentication, only kerberos. > > I guess that the use cases where a kernel without these algorithms are > present are ok with kerberos as the > only authentication mech. Well, maybe. Even without kerberos, would it still be possible to use SMB with a "guest" user only? > > Afaik arc4 is only used for signing in the smb1 case. > > > > > Also, there's already an option CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n which > > disables support for SMB2.0 and earlier. However, it doesn't actually compile > > out the code but rather just prevents it from being used. That means that the > > DES and ARC4 library interfaces are still depended on at link time, so they > > can't be omitted. Have there been any considerations towards making > > CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n compile out the code for SMB2.0 and earlier? > > I think initially we just wanted to disable its use. If we want to > compile a kernel completely without arc4/md4/md5 I think we would need > to: > > 1, Change CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n to compile out the code > as you suggests. > This should remove the dependency for arc4. I think this would be a > good thing to do. > > 2, Have a different CONFIG_... to compile out the use of NTLMSSP > authentication. This must be a different define > since md4/md5 are also used for non-legacy dialects. > And this should remove the dependency of md4/5. > > For the latter, I guess we would need a global, i.e. not > cifs-specific, config option for this. I assume other users of > rc4/md4/md5 > would also want this. > A new CONFIG_INSECURE_CRYPTO=n ? There is already an option CRYPTO_USER_API_ENABLE_OBSOLETE that could be renamed and reused if we wanted to expand its scope to all insecure crypto. Although a one-size-fits all kernel-wide option controlling "insecure" crypto could be controversial, as there is no consensus whether some crypto algorithms are secure or not, and different subsystems have different constraints. - Eric
