On Tue, 17 Aug 2021 at 00:19, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Sun, Aug 15, 2021 at 08:38:23PM +1000, ronnie sahlberg wrote: > > > > What are the plans here? To just offer the possibility to disable all > > these old crypto and hashes on a local kernel compile? > > Or is the plan to just outright remove it from the kernel sources? > > > > If the first, I think that could possible be done for cifs. I think a > > lot of the security minded larger enterprises already may be disabling > > both SMB1 and also NTLM on serverside, so they would be fine. > > > > For the latter, I think it would be a no-go since aside from krb5 > > there are just no other viable authentication mechs for smb. > > Removing the code would be best, but allowing it to be compiled out would be the > next best thing. > > > TL;DR > > If NTLMSSP authentication is disabled, there are no other options to > > map a share than using KRB5 > > and setting up the krb5 infrastructure. And thus smaller sites will > > not be able to use CIFS :-( > > So while I think it is feasible to add support to cifs.ko to > > conditionally disable features depending in a kernel compile (no SMB1 > > if des/rc4 is missing, no NTLM if rc4/md4/md5 is missing) I don't > > think it is feasible to disable these by default. > > I will work on making it possible to build cifs.ko with limied > > functionality when these algorithms are disabled though. > > FWIW, the way this came up is that the Compatibility Test Suite for Android 11 > verifies that CONFIG_CRYPTO_MD4 isn't set. The reason that test got added is > because for a short time, CONFIG_CRYPTO_MD4 had accidentally been enabled in the > recommended kernel config for Android. Since "obviously" no one would be using > a completely broken crypto algorithm from 31 years ago, when fixing that bug we > decided to go a bit further and just forbid it from the kernel config. > > I guess we'll have to remove that test for now (assuming that CONFIG_CIFS is to > be allowed at all on an Android device, and that the people who want to use it > don't want to use kerberos which is probably the case). > > It is beyond ridiculous that this is even an issue though, given that MD4 has > been severely compromised for over 25 years. > > One thing which we should seriously consider doing is removing md4 from the > crypto API and moving it into fs/cifs/. It isn't a valid crypto algorithm, so > anyone who wants to use it should have to maintain it themselves. > +1 to moving the md4 code into fs/cifs, so that the CIFS maintainers can own it and phase it out on their own schedule, and prevent its inadvertent use in other places.
