linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: linux-cifs <linux-cifs@vger.kernel.org>,
	Steve French <sfrench@samba.org>,
	"samba-technical@lists.samba.org"
	<samba-technical@lists.samba.org>,
	linux-crypto@vger.kernel.org
Subject: Re: Building cifs.ko without any support for insecure crypto?
Date: Fri, 13 Aug 2021 13:19:56 -0700	[thread overview]
Message-ID: <YRbT7IbSCXo4Dl0u@sol.localdomain> (raw)
In-Reply-To: <CAN05THSm5fEcnLKxcsidKPRUC6PVLCkWMBZUW05KNm4uMJNHWw@mail.gmail.com>

On Fri, Aug 13, 2021 at 02:46:21PM +1000, ronnie sahlberg wrote:
> On Fri, Aug 13, 2021 at 1:34 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Hi!
> >
> > We should be working to eliminate any uses of insecure crypto algorithms (e.g.
> > DES, ARC4, MD4, MD5) from the kernel.  In particular, it should be possible to
> > build a kernel for a modern system without including any such algorithms.
> >
> > Currently, CONFIG_CIFS is problematic because it selects all these algorithms
> > (kconfig options: CONFIG_CRYPTO_LIB_DES, CONFIG_CRYPTO_LIB_ARC4,
> > CONFIG_CRYPTO_MD4, CONFIG_CRYPTO_MD5).
> >
> > It looks like these algorithms might only be used by SMB2.0 and earlier, and the
> > more modern SMB versions don't use them.  Is that the case?  It mostly looks
> > like that, but there's one case I'm not sure about -- there's a call chain which
> > appears to use ARC4 and HMAC-MD5 even with the most recent SMB version:
> >
> >     smb311_operations.sess_setup()
> >       SMB2_sess_setup()
> >         SMB2_sess_auth_rawntlmssp_authenticate()
> >           build_ntlmssp_auth_blob()
> >             setup_ntlmv2_rsp()
> 
> md4 and md5 are used with the NTLMSSP authentication for all dialects,
> including the latest 3.1.1.

That's unfortunate.  Surely Microsoft knows that md4 has been severely
compromised for over 25 years?  And md5 for 15 years.

> The only other authentication mechanism for SMB is krb5.

Is the long-term plan to have everyone migrate to kerberos?  Currently kerberos
doesn't appear to be the default, so not many people actually use it -- right?

> This means that if we build a kernel without md4/md5 then we can no
> longer use NTLMSSP user/password
> style authentication, only kerberos.
>
> I guess that the use cases where a kernel without these algorithms are
> present are ok with kerberos as the
> only authentication mech.

Well, maybe.  Even without kerberos, would it still be possible to use SMB with
a "guest" user only?

> 
> Afaik arc4 is only used for signing in the smb1 case.
> 
> >
> > Also, there's already an option CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n which
> > disables support for SMB2.0 and earlier.  However, it doesn't actually compile
> > out the code but rather just prevents it from being used.  That means that the
> > DES and ARC4 library interfaces are still depended on at link time, so they
> > can't be omitted.  Have there been any considerations towards making
> > CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n compile out the code for SMB2.0 and earlier?
> 
> I think initially we just wanted to disable its use. If we want to
> compile a kernel completely without arc4/md4/md5 I think we would need
> to:
> 
> 1, Change CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n to compile out the code
> as you suggests.
> This should remove the dependency for arc4. I think this would be a
> good thing to do.
> 
> 2, Have a different CONFIG_... to compile out the use of NTLMSSP
> authentication. This must be a different define
> since md4/md5 are also used for non-legacy dialects.
> And this should remove the dependency of md4/5.
> 
> For the latter, I guess we would need a global, i.e. not
> cifs-specific, config option for this. I assume other users of
> rc4/md4/md5
> would also want this.
> A new CONFIG_INSECURE_CRYPTO=n ?

There is already an option CRYPTO_USER_API_ENABLE_OBSOLETE that could be
renamed and reused if we wanted to expand its scope to all insecure crypto.

Although a one-size-fits all kernel-wide option controlling "insecure" crypto
could be controversial, as there is no consensus whether some crypto algorithms
are secure or not, and different subsystems have different constraints.

- Eric

  reply	other threads:[~2021-08-13 20:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  3:23 Building cifs.ko without any support for insecure crypto? Eric Biggers
2021-08-13  4:46 ` ronnie sahlberg
2021-08-13 20:19   ` Eric Biggers [this message]
2021-08-15 10:38     ` ronnie sahlberg
2021-08-16 22:19       ` Eric Biggers
2021-08-17  5:35         ` Steve French
2021-08-18 11:44         ` Ard Biesheuvel
2021-08-19  3:43           ` ronnie sahlberg
2021-08-19  3:53             ` Andrew Bartlett
2021-08-23 10:04             ` Simo Sorce
2021-08-24 16:41               ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRbT7IbSCXo4Dl0u@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).