archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <>
To: ronnie sahlberg <>
Cc: linux-cifs <>,
	Steve French <>,
Subject: Re: Building cifs.ko without any support for insecure crypto?
Date: Mon, 16 Aug 2021 15:19:51 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Aug 15, 2021 at 08:38:23PM +1000, ronnie sahlberg wrote:
> What are the plans here? To just offer the possibility to disable all
> these old crypto and hashes on a local kernel compile?
> Or is the plan to just outright remove it from the kernel sources?
> If the first, I think that could possible be done for cifs. I think a
> lot of the security minded larger enterprises already may be disabling
> both SMB1 and also NTLM on serverside, so they would be fine.
> For the latter, I think it would be a no-go since aside from krb5
> there are just no other viable authentication mechs for smb.

Removing the code would be best, but allowing it to be compiled out would be the
next best thing.

> If NTLMSSP authentication is disabled, there are no other options to
> map a share than using KRB5
> and setting up the krb5 infrastructure. And thus smaller sites will
> not be able to use CIFS :-(
> So while I think it is feasible to add support to cifs.ko to
> conditionally disable features depending in a kernel compile (no SMB1
> if des/rc4 is missing, no NTLM if rc4/md4/md5 is missing)  I don't
> think it is feasible to disable these by default.
> I will work on making it possible to build cifs.ko with limied
> functionality when these algorithms are disabled though.

FWIW, the way this came up is that the Compatibility Test Suite for Android 11
verifies that CONFIG_CRYPTO_MD4 isn't set.  The reason that test got added is
because for a short time, CONFIG_CRYPTO_MD4 had accidentally been enabled in the
recommended kernel config for Android.  Since "obviously" no one would be using
a completely broken crypto algorithm from 31 years ago, when fixing that bug we
decided to go a bit further and just forbid it from the kernel config.

I guess we'll have to remove that test for now (assuming that CONFIG_CIFS is to
be allowed at all on an Android device, and that the people who want to use it
don't want to use kerberos which is probably the case).

It is beyond ridiculous that this is even an issue though, given that MD4 has
been severely compromised for over 25 years.

One thing which we should seriously consider doing is removing md4 from the
crypto API and moving it into fs/cifs/.  It isn't a valid crypto algorithm, so
anyone who wants to use it should have to maintain it themselves.

- Eric

  reply	other threads:[~2021-08-16 22: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
2021-08-15 10:38     ` ronnie sahlberg
2021-08-16 22:19       ` Eric Biggers [this message]
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:

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

  git send-email \ \ \ \ \ \ \ \

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