On Fri, Aug 20, 2021 at 3:10 AM Steve French <smfrench@xxxxxxxxx> wrote: > > On Thu, Aug 19, 2021 at 5:42 AM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote: > > > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@xxxxxxxxx> > > > wrote: > > > > Hi Ard, > > > > > > > > On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > > > > > As discussed on the list [0], MD4 is still being relied upon by > > > > > the CIFS > > > > > driver, even though successful attacks on MD4 are as old as Linux > > > > > itself. > > > > > > > > > > So let's move the code into the CIFS driver, and remove it from > > > > > the > > > > > crypto API so that it is no longer exposed to other subsystems or > > > > > to > > > > > user space via AF_ALG. > > > > > > > > > > > > > Can we please stop removing algorithms from AF_ALG? > > > > > > I don't think we can, to be honest. We need to have a deprecation > > > path > > > for obsolete and insecure algorithms: the alternative is to keep > > > supporting a long tail of broken crypto indefinitely. > > > > I think you are ignoring the fact that by doing that you might be > > removing a migration path to more secure algorithms, for some legacy > > systems. > > > > I.e. in some cases this might mean sticking to insecure algorithm *and* > > old kernel for unnecessary long amount of time because migration is > > more costly. > > > > Perhaps there could be a comman-line parameter or similar to enable > > legacy crypto? > > There are. For example less secure NTLMv1 is disabled in the build. > On the command line "sec=krb5" will use kerberos, and we can move that > to be the default, > or at least autonegotiate it, but will require some minor changes to > cifs-utils to detect if > plausible Kerberos ticket is available for this mount before > requesting krb5 automatically. > > But ... we already have parameters to disable SMB1, and in fact if you > mount with > "mount -t smb3 ..." we won't let you use SMB1 or SMB2 so we get the > security advantages > of preventing man-in-the-middle attacks during negotiation and encryption etc. > In addition, SMB1 can be disabled completely by simply doing > > "echo 1 > /sys/module/cifs/parameters/disable_legacy_dialects" > > but even without that, to mount insecurely with SMB1 requires > specifying it (vers=1.0) on the command line. > > In addition requiring the strongest encryption can be set by > > "echo 1 > /sys/module/parameters/cifs/require_gcm_256" > > > Although moving to a peer to peer auth solution better than NTLMSSP is > something important to do ASAP Agreed. We need a new peer-to-peer authentication mechanism. But this is storage so things move slowly and we can't remove a feature that hundreds of millions of people depend on and break their environments just because "need tickbox". As an example of how long it takes to migrate to a different solution in mass deployed storage technologies just look at SMB1. The whole industry has been working hard and as fast as possible to move away from SMB1 since 2006 and we are still NOT at the stage where we can delete this functionality. Disable it by default for some configurations but delete? No. Even if we get a new peer-to-peer mechanism today, it will take up to 20 years before we will be able to delete MD4 support in the linux kernel for CIFS. Unless we want a wildly disruptive event where we either break storage for hundreds of millions of people or we force them to remain on 5.13 for the next 20 years. Storage is not the same as a cell-phone, or some consumer device where you can drop support or break them every few years. The timelines for migrating in storage is measured in decades. But I guess we will have a loadable module for MD4 in cifs that both the cifs client and the cifs server will be able to use. Other subsystems that have hard dependency on MD4 and can not just break their users can probably also just use the cifs_md4 module too if they want to. At least we can try to avoid a situation where we will have multiple different MD4 implementations for the next decade or two in the kernel. > (we should follow up e.g. on making sure we work with the "peer to > peer Kerberos" (which is used by Apple > for this purpose) see e.g. > https://discussions-cn-prz.apple.com/en/thread/252949265) > > Andrew Bartlett's note explains the bigger picture well: > > "I would echo that, and also just remind folks that MD4 in NTLMSSP is > used as a compression only, it has no security value. The security > would be the same if the password was compressed with MD4, SHA1 or > SHA256 - the security comes from the complexity of the password and the > HMAC-MD5 rounds inside NTLMv2. > > I'll also mention the use of MD4, which is used to re-encrypt a short- > term key with the long-term key out of the NTLMv2 scheme. This > thankfully is an unchecksumed simple RC4 round of one random value with > another, so not subject to known-plaintext attacks here. I know neither > MD4 nor HMAC-MD5 is not flavour of the month any more, > with good reason, but we would not want to go with way of NFSv4 which > is, as I understand it, full Kerberos or bust (so folks choose no > protection)." > > "Thankfully only the HMAC-MD5 step in what you mention is > cryptographically significant, the rest are just very lossy compression > algorithms." > > > > -- > Thanks, > > Steve
