[PATCH 0/2] crypto: remove MD4 generic shash

[PATCH 0/2] crypto: remove MD4 generic shash

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

Note: this leaves the code in crypto/asymmetric_keys that is able to
parse RSA+MD4 keys if an "md4" shash is available. Given that its
Kconfig symbol does not select CRYPTO_MD4, it only has a runtime
dependency on md4 and so we can either decide remove it later, or just
let it fail on the missing MD4 shash as it would today if the module is
not enabled.

[0] https://lore.kernel.org/linux-cifs/YRXlwDBfQql36wJx@sol.localdomain/

Cc: Eric Biggers <ebiggers@kernel.org>
Cc: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: linux-cifs <linux-cifs@vger.kernel.org>
Cc: Steve French <sfrench@samba.org>
Cc: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org

Ard Biesheuvel (2):
  fs/cifs: Incorporate obsolete MD4 crypto code
  crypto: md4 - Remove obsolete algorithm

 crypto/Kconfig       |   6 -
 crypto/Makefile      |   1 -
 crypto/md4.c         | 241 --------------------
 crypto/tcrypt.c      |  14 +-
 crypto/testmgr.c     |   6 -
 crypto/testmgr.h     |  42 ----
 fs/cifs/Kconfig      |   1 -
 fs/cifs/cifsfs.c     |   1 -
 fs/cifs/smbencrypt.c | 200 ++++++++++++++--
 9 files changed, 178 insertions(+), 334 deletions(-)
 delete mode 100644 crypto/md4.c

-- 
2.20.1

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Denis Kenzior]

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?  The previous ARC4 removal 
already caused some headaches [0].  Please note that iwd does use MD4 for MSCHAP 
and MSCHAPv2 based 802.1X authentication.

Regards,
-Denis

[0] https://bugs.launchpad.net/ubuntu/+source/iwd/+bug/1938650

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Ard Biesheuvel]

On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com> 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.

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

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

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Denis Kenzior]

Hi Ard,

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

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

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

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

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Steve French]

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)

On Wed, Aug 18, 2021 at 11:24 AM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Ard,
>
> >>   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.
>
> 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...
>
> >
> >>   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.
> >
>
> 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



-- 
Thanks,

Steve

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Jeremy Allison]

On Wed, Aug 18, 2021 at 11:47:53AM -0500, Steve French via samba-technical wrote:
>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.

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Andrew Bartlett]

On Wed, 2021-08-18 at 15:08 -0700, Jeremy Allison via samba-technical
wrote:
> 
> 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 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).

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Eric Biggers]

On Thu, Aug 19, 2021 at 03:49:14PM +1200, Andrew Bartlett wrote:
> 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.

- Eric

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Andrew Bartlett]

On Wed, 2021-08-18 at 22:18 -0700, Eric Biggers wrote:

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

I'm sorry that Samba - or the Kernel, you could implement whatever is
desired between cifs.ko and kcifsd -  hasn't gone it alone to build a
new peer-to-peer mechanism, but absent a Samba-only solution Microsoft
has been asked and has no intention of updating NTLM, so embarrassing
or otherwise this is how it is.

Thankfully only the HMAC-MD5 step in what you mention is
cryptographically significant, the rest are just very lossy compression
algorithms.  

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[ronnie sahlberg]

On Thu, Aug 19, 2021 at 2:23 AM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Ard,
>
> >>   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.
>
> 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...
>
> >
> >>   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.
> >
>
> 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.

The same situation exist for cifs. The cifs client depends on md4 in
order to authenticate to Windows/Azure/Samba/... cifs servers.
And like you we have no control of the servers.

Our solution will likely be to fork the md4 code and put a private
copy in our module.
Maybe you need to do the same.

--
ronnie

>
> Regards,
> -Denis

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Ard Biesheuvel]

On Wed, 18 Aug 2021 at 18:23, Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Ard,
>
> >>   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.
>
> 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...
>

Fair enough.

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

Does that code rely on MD4 as well?

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Denis Kenzior]

Hi Ard,

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

>> are still surprisingly many today.
>>
> 
> 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.

MD4 is used to hash the plaintext password, but the hash is sent inside a TLS 
tunnel, so there's really no immediate crypto weakness concern?  At least 
there's not a replacement on the horizon as far as I know.  EAP-PWD has its own 
problems and I doubt certificate based authentication will overtake 
username/password any time soon.

Regards,
-Denis

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Steve French]

On Wed, Aug 18, 2021 at 5:22 PM Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Ard,
>
> >> 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.
>
> >> are still surprisingly many today.
> >>
> >
> > 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.

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?



-- 
Thanks,

Steve

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Denis Kenzior]

Hi Steve,

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

What background are you looking for?  iwd [0] is a wifi management daemon, so we 
implement various EAP [1] and wifi authentication protocols.

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

You are quite correct.  MSCHAPv2 also uses DES for generating the responses. 
EAP with TTLS+MSCHAPv2 and PEAP+MSCHAPv2 are two of the most deployed variants 
of WPA-Enterprise authentication using Username + Password.

Deprecating MD4, MD5, SHA1 or DES would be quite disruptive for us.  We are 
using these through AF_ALG userspace API, so if they're removed, some 
combination of kernel + iwd version will break.  We went through this with ARC4, 
and while that was justified, I don't think the same justification exists for MD4.

[0] https://git.kernel.org/pub/scm/network/wireless/iwd.git
[1] https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol

Regards,
-Denis

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Jarkko Sakkinen]

On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote:
> On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com>
> 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?

/Jarkko

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[Steve French]

On Thu, Aug 19, 2021 at 5:42 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote:
> > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com>
> > 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

Re: [PATCH 0/2] crypto: remove MD4 generic shash

[ronnie sahlberg]

On Fri, Aug 20, 2021 at 3:10 AM Steve French <smfrench@gmail.com> wrote:
>
> On Thu, Aug 19, 2021 at 5:42 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote:
> > > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com>
> > > 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