crypto: remove MD4 generic shash

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.

Hi Ard,

Quoted 4 lines · Ard Biesheuvel

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.

Quoted 4 lines

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?

The previous ARC4 removal
already caused some headaches [0].

Please note that iwd does use MD4 for MSCHAP
and MSCHAPv2 based 802.1X authentication.

Quoted 2 lines

The previous ARC4 removal
already caused some headaches [0].

This is the first time this has been reported on an upstream kernel list.

As you know, I went out of my way to ensure that this removal would happen as smoothly as possible, which is why I contributed code to both iwd and libell beforehand, and worked with distros to ensure that the updated versions would land before the removal of ARC4 from the kernel.

It is unfortunate that one of the distros failed to take that into account for the backport of a newer kernel to an older distro release, but I don't think it is fair to blame that on the process.

Quoted 4 lines

Please note that iwd does use MD4 for MSCHAP
and MSCHAPv2 based 802.1X authentication.

Thanks for reporting that.

So what is your timeline for retaining MD4 support in iwd? You are aware that it has been broken since 1991, right? Please, consider having a deprecation path, so we can at least agree on *some* point in time (in 6 months, in 6 years, etc) where we can start culling this junk.

Hi Ard,

Quoted 11 lines

Quoted 2 lines

The previous ARC4 removal
already caused some headaches [0].

This is the first time this has been reported on an upstream kernel list.

As you know, I went out of my way to ensure that this removal would happen as smoothly as possible, which is why I contributed code to both iwd and libell beforehand, and worked with distros to ensure that the updated versions would land before the removal of ARC4 from the kernel.

Quoted 3 lines

It is unfortunate that one of the distros failed to take that into account for the backport of a newer kernel to an older distro release, but I don't think it is fair to blame that on the process.

Please don't misunderstand, I don't blame you at all. I was in favor of ARC4 removal since the kernel AF_ALG implementation was broken and the ell implementation had to work around that. And you went the extra mile to make sure the migration was smooth. The reported bug is still a fairly minor inconvenience in the grand scheme of things.

But, I'm not in favor of doing the same for MD4...

Quoted 5 lines

Quoted 4 lines

Please note that iwd does use MD4 for MSCHAP
and MSCHAPv2 based 802.1X authentication.

Quoted 8 lines

Thanks for reporting that.

So what is your timeline for retaining MD4 support in iwd? You are aware that it has been broken since 1991, right? Please, consider having a deprecation path, so we can at least agree on *some* point in time (in 6 months, in 6 years, etc) where we can start culling this junk.

That is not something that iwd has any control over though? We have to support it for as long as there are organizations using TTLS + MD5 or PEAPv0. There are still surprisingly many today.

Regards,
-Denis

I don't object to moving ARC4 and/or MD4 into cifs.ko, but we do have to be careful that we don't make the defaults "less secure" as an unintentional side effect.

The use of ARC4 and MD4 is the NTLMSSP authentication workflow is relatively small (narrow use case), and NTLMSSP is the default for many servers and clients - and some of the exploits do not apply in the case of SMB2.1 and later (which is usually required on mount in any case).

There is little argument that kerberos ("sec=krb5") is more secure and does not rely on these algorithms ... but there are millions of devices (probably over 100 million) that can support SMB3.1.1 (or at least SMB3) mounts but couldn't realistically join a domain and use "sec=krb5" so would be forced to use "guest" mounts (or in the case of removing RC4 use less secure version of NTLMSSP).

In the longer term where I would like this to go is:
- make it easier to "require Kerberos" (in module load parameters for cifs.ko)
- make sure cifs.ko builds even if these algorithms are removed from the kernel, and that mount by default isn't broken if the user chooses to build without support for NTLMSSP, the default auth mechanism (ie NTLMSSP being disabled because required crypto algorithms aren't available)
- add support in Linux for a "peer to peer" auth mechanism (even if it requires an upcall), perhaps one that is certificate based and one that is not (and thus much easier to use) that we can plumb into
SPNEGO (RFC2478). By comparison, it sounds like it is much easier

in Windows to add in additional authentication mechanisms (beyond Kerberos, PKU2U and NTLMSSP) - see
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj852232(v=ws.11)
so perhaps we just need to do something similar for the kernel client and samba and ksmbd where they call out to a library which is configured to provide the SPNEGO blobs for the new stronger peer-to-peer authentication mechanism the distro chooses to enable (for cases where using Kerberos for authentication is not practical)

My 2 cents. Preventing NTLM authentication/signing from working would be
a negative for the Linux kernel client. I don't mind if that code has to be isolated inside cifs.ko, but it really needs to keep working, at least until we have a pluggable client auth in cifs.ko and Samba that allows the single-server (non AD-Domain) case to keep working easily.

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).

I'm not sure you understand how embarrassing it is to still be using these
algorithms. MD4 has been broken for over 25 years, and better algorithms have
been recommended for 29 years. Similarly MD5 has been broken for 16 years and
better algorithms have been recommended for 25 years (though granted, HMAC-MD5
is more secure than plain MD5 when properly used). Meanwhile SHA-2 is 20 years
old and is still considered secure. So this isn't something that changes every
month -- we're talking about no one bothering to do anything in 30 years.

Of course, if cryptography isn't actually applicable to the use case, then
cryptography shouldn't be used at all.

Hi Ard,

Quoted 11 lines

Quoted 2 lines

The previous ARC4 removal
already caused some headaches [0].

This is the first time this has been reported on an upstream kernel list.

As you know, I went out of my way to ensure that this removal would happen as smoothly as possible, which is why I contributed code to both iwd and libell beforehand, and worked with distros to ensure that the updated versions would land before the removal of ARC4 from the kernel.

Quoted 3 lines

It is unfortunate that one of the distros failed to take that into account for the backport of a newer kernel to an older distro release, but I don't think it is fair to blame that on the process.

Please don't misunderstand, I don't blame you at all. I was in favor of ARC4 removal since the kernel AF_ALG implementation was broken and the ell implementation had to work around that. And you went the extra mile to make sure the migration was smooth. The reported bug is still a fairly minor inconvenience in the grand scheme of things.

But, I'm not in favor of doing the same for MD4...

Quoted 5 lines

Quoted 4 lines

Please note that iwd does use MD4 for MSCHAP
and MSCHAPv2 based 802.1X authentication.

Quoted 8 lines

Thanks for reporting that.

So what is your timeline for retaining MD4 support in iwd? You are aware that it has been broken since 1991, right? Please, consider having a deprecation path, so we can at least agree on *some* point in time (in 6 months, in 6 years, etc) where we can start culling this junk.

That is not something that iwd has any control over though? We have to support it for as long as there are organizations using TTLS + MD5 or PEAPv0. There are still surprisingly many today.

Regards,
-Denis

Hi Ard,

Quoted 11 lines

Quoted 2 lines

The previous ARC4 removal
already caused some headaches [0].

This is the first time this has been reported on an upstream kernel list.

As you know, I went out of my way to ensure that this removal would happen as smoothly as possible, which is why I contributed code to both iwd and libell beforehand, and worked with distros to ensure that the updated versions would land before the removal of ARC4 from the kernel.

Quoted 3 lines

It is unfortunate that one of the distros failed to take that into account for the backport of a newer kernel to an older distro release, but I don't think it is fair to blame that on the process.

Please don't misunderstand, I don't blame you at all. I was in favor of ARC4 removal since the kernel AF_ALG implementation was broken and the ell implementation had to work around that. And you went the extra mile to make sure the migration was smooth. The reported bug is still a fairly minor inconvenience in the grand scheme of things.

But, I'm not in favor of doing the same for MD4...

Quoted 5 lines

Quoted 4 lines

Please note that iwd does use MD4 for MSCHAP
and MSCHAPv2 based 802.1X authentication.

Quoted 8 lines

Thanks for reporting that.

So what is your timeline for retaining MD4 support in iwd? You are aware that it has been broken since 1991, right? Please, consider having a deprecation path, so we can at least agree on *some* point in time (in 6 months, in 6 years, etc) where we can start culling this junk.

That is not something that iwd has any control over though? We have to support it for as long as there are organizations using TTLS + MD5 or PEAPv0. There are still surprisingly many today.

Quoted 2 lines

That is not something that iwd has any control over though? We have to support it for as long as there are organizations using TTLS + MD5 or PEAPv0. There

Quoted 2 lines

are still surprisingly many today.

Does that code rely on MD4 as well?

Hi Ard,

Quoted 2 lines

Quoted 2 lines

That is not something that iwd has any control over though? We have to support it for as long as there are organizations using TTLS + MD5 or PEAPv0. There

Ah, my brain said MSCHAP but my fingers typed MD5.

Quoted 3 lines

Quoted 2 lines

are still surprisingly many today.

Quoted 2 lines

Does that code rely on MD4 as well?

But the answer is yes. Both PEAP and TTLS use MSCHAP or MSCHAPv2 in some form.
These are commonly used for Username/Password based WPA(2|3)-Enterprise
authentication. Think 'eduroam' for example.

Quoted 3 lines

But the answer is yes. Both PEAP and TTLS use MSCHAP or MSCHAPv2 in some form.
These are commonly used for Username/Password based WPA(2|3)-Enterprise
authentication. Think 'eduroam' for example.

Can you give some background here? IIRC MS-CHAPv2 is much worse than the NTLMSSP case

in cifs.ko (where RC4/MD5 is used narrowly). Doesn't MS-CHAPv2 depend on DES?

Quoted 15 lines · Denis Kenzior

Hi Ard,

Quoted 11 lines · Ard Biesheuvel

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.

Quoted 1 line

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.

Quoted 17 lines · Ard Biesheuvel

Quoted 15 lines · Denis Kenzior

Hi Ard,

Quoted 11 lines · Ard Biesheuvel

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.

Quoted 6 lines

Quoted 1 line

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?

Quoted 30 lines · Jarkko Sakkinen

Quoted 17 lines · Ard Biesheuvel

Quoted 15 lines · Denis Kenzior

Hi Ard,

Quoted 11 lines · Ard Biesheuvel

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 6 lines

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