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 (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
