Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #69359 > unrolled thread

please consider disabling obsolete crypto in 5.10 and later

Back to article view | Back to linux.debian.kernel

Contents

  please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-01-30 17:10 +0100
    Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-02-01 22:30 +0100
      Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-02-06 00:10 +0100
      Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-02-25 11:40 +0100
        Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-02-25 12:30 +0100
          Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-03-09 18:10 +0100
            Re: please consider disabling obsolete crypto in 5.10 and later Salvatore Bonaccorso <carnil@debian.org> - 2021-03-10 14:40 +0100
              Re: please consider disabling obsolete crypto in 5.10 and later Ard Biesheuvel <ardb@kernel.org> - 2021-03-10 15:00 +0100

#69359 — please consider disabling obsolete crypto in 5.10 and later

L.S.,

This is a request to consider disabling obsolete crypto in 5.10 and
later Debian builds of the Linux kernel on any architecture.

We are all familiar with the rigid rules when it comes to not breaking
userspace by making changes to the kernel, but this rule only takes
effect when anybody notices, and so I am proposing disabling some code
downstream before removing it entirely.

5.10 introduces a new Kconfig symbol

CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE

which is enabled by default, but depends on support for the AF_ALG
socket API being enabled. In turn, block ciphers that are obsolete and
unlikely to be used anywhere have been made to depend on this new
symbol.

This means that these obsolete block ciphers will disappear entirely
when the AF_ALG socket API is omitted, but we can get rid of these
block ciphers explicitly too, by not setting the new symbol. I.e.,
adding

# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

to the kernel configs. Note that Fedora have already done so in release 33 [0]

The block ciphers in question are RC4, Khazad, SEED, and
TEA/XTEA/XETA, none of which are used by the kernel itself, or known
to be used via the socket API (although a change was applied to
iwd/libell recently to get rid of an occurrence of RC4 - this change
has already been pulled into bullseye afaik)

Note that this is not a statement on whether these algorithms are
secure or not -there is simply no point in carrying and shipping code
that nobody uses or audits, but which can be autoloaded and exercised
via an unprivileged interface.

--
Ard.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=f33

[toc] | [next] | [standalone]

#69397

Hi Ard,

On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> L.S.,
> 
> This is a request to consider disabling obsolete crypto in 5.10 and
> later Debian builds of the Linux kernel on any architecture.
> 
> We are all familiar with the rigid rules when it comes to not breaking
> userspace by making changes to the kernel, but this rule only takes
> effect when anybody notices, and so I am proposing disabling some code
> downstream before removing it entirely.
> 
> 5.10 introduces a new Kconfig symbol
> 
> CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> 
> which is enabled by default, but depends on support for the AF_ALG
> socket API being enabled. In turn, block ciphers that are obsolete and
> unlikely to be used anywhere have been made to depend on this new
> symbol.
> 
> This means that these obsolete block ciphers will disappear entirely
> when the AF_ALG socket API is omitted, but we can get rid of these
> block ciphers explicitly too, by not setting the new symbol. I.e.,
> adding
> 
> # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> 
> to the kernel configs. Note that Fedora have already done so in release 33 [0]
> 
> The block ciphers in question are RC4, Khazad, SEED, and
> TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> to be used via the socket API (although a change was applied to
> iwd/libell recently to get rid of an occurrence of RC4 - this change
> has already been pulled into bullseye afaik)
> 
> Note that this is not a statement on whether these algorithms are
> secure or not -there is simply no point in carrying and shipping code
> that nobody uses or audits, but which can be autoloaded and exercised
> via an unprivileged interface.

FTR (posteriori), we tried that in
https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
(and is in the 5.10.12-1 upload to unstable).

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#69443

On Mon, 1 Feb 2021 at 22:21, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi Ard,
>
> On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > L.S.,
> >
> > This is a request to consider disabling obsolete crypto in 5.10 and
> > later Debian builds of the Linux kernel on any architecture.
> >
> > We are all familiar with the rigid rules when it comes to not breaking
> > userspace by making changes to the kernel, but this rule only takes
> > effect when anybody notices, and so I am proposing disabling some code
> > downstream before removing it entirely.
> >
> > 5.10 introduces a new Kconfig symbol
> >
> > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> >
> > which is enabled by default, but depends on support for the AF_ALG
> > socket API being enabled. In turn, block ciphers that are obsolete and
> > unlikely to be used anywhere have been made to depend on this new
> > symbol.
> >
> > This means that these obsolete block ciphers will disappear entirely
> > when the AF_ALG socket API is omitted, but we can get rid of these
> > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > adding
> >
> > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> >
> > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> >
> > The block ciphers in question are RC4, Khazad, SEED, and
> > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > to be used via the socket API (although a change was applied to
> > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > has already been pulled into bullseye afaik)
> >
> > Note that this is not a statement on whether these algorithms are
> > secure or not -there is simply no point in carrying and shipping code
> > that nobody uses or audits, but which can be autoloaded and exercised
> > via an unprivileged interface.
>
> FTR (posteriori), we tried that in
> https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> (and is in the 5.10.12-1 upload to unstable).
>

Confirmed, thanks.

[toc] | [prev] | [next] | [standalone]

#69614

Hi Ard,

On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote:
> Hi Ard,
> 
> On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > L.S.,
> > 
> > This is a request to consider disabling obsolete crypto in 5.10 and
> > later Debian builds of the Linux kernel on any architecture.
> > 
> > We are all familiar with the rigid rules when it comes to not breaking
> > userspace by making changes to the kernel, but this rule only takes
> > effect when anybody notices, and so I am proposing disabling some code
> > downstream before removing it entirely.
> > 
> > 5.10 introduces a new Kconfig symbol
> > 
> > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > 
> > which is enabled by default, but depends on support for the AF_ALG
> > socket API being enabled. In turn, block ciphers that are obsolete and
> > unlikely to be used anywhere have been made to depend on this new
> > symbol.
> > 
> > This means that these obsolete block ciphers will disappear entirely
> > when the AF_ALG socket API is omitted, but we can get rid of these
> > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > adding
> > 
> > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > 
> > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> > 
> > The block ciphers in question are RC4, Khazad, SEED, and
> > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > to be used via the socket API (although a change was applied to
> > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > has already been pulled into bullseye afaik)
> > 
> > Note that this is not a statement on whether these algorithms are
> > secure or not -there is simply no point in carrying and shipping code
> > that nobody uses or audits, but which can be autoloaded and exercised
> > via an unprivileged interface.
> 
> FTR (posteriori), we tried that in
> https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> (and is in the 5.10.12-1 upload to unstable).

There were two reports which might be in the end related to that
change:

https://bugs.debian.org/979764
https://bugs.debian.org/983508

We have long that nfs-utils need to be updated, but the version was so
outdated, that progress on updating to a newer version stalled, and
could not be done in time for bulleye. Once bullseye is released I
guess this really needs to be prioritzed in some way.

Ard, have you any insight in the above, so, should we revert the above
change for bullseye again?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#69615

On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi Ard,
>
> On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote:
> > Hi Ard,
> >
> > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > > L.S.,
> > >
> > > This is a request to consider disabling obsolete crypto in 5.10 and
> > > later Debian builds of the Linux kernel on any architecture.
> > >
> > > We are all familiar with the rigid rules when it comes to not breaking
> > > userspace by making changes to the kernel, but this rule only takes
> > > effect when anybody notices, and so I am proposing disabling some code
> > > downstream before removing it entirely.
> > >
> > > 5.10 introduces a new Kconfig symbol
> > >
> > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > >
> > > which is enabled by default, but depends on support for the AF_ALG
> > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > unlikely to be used anywhere have been made to depend on this new
> > > symbol.
> > >
> > > This means that these obsolete block ciphers will disappear entirely
> > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > adding
> > >
> > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > >
> > > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> > >
> > > The block ciphers in question are RC4, Khazad, SEED, and
> > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > to be used via the socket API (although a change was applied to
> > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > has already been pulled into bullseye afaik)
> > >
> > > Note that this is not a statement on whether these algorithms are
> > > secure or not -there is simply no point in carrying and shipping code
> > > that nobody uses or audits, but which can be autoloaded and exercised
> > > via an unprivileged interface.
> >
> > FTR (posteriori), we tried that in
> > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > (and is in the 5.10.12-1 upload to unstable).
>
> There were two reports which might be in the end related to that
> change:
>
> https://bugs.debian.org/979764
> https://bugs.debian.org/983508
>
> We have long that nfs-utils need to be updated, but the version was so
> outdated, that progress on updating to a newer version stalled, and
> could not be done in time for bulleye. Once bullseye is released I
> guess this really needs to be prioritzed in some way.
>
> Ard, have you any insight in the above, so, should we revert the above
> change for bullseye again?
>

Hello Salvatore,

I think the issue is the patch below. Having something that requires
RC4 and MD5 for security is an absolute joke in 2021, so I won't
recommend you reverting it. Instead, you should really fix nfs-utils
with priority.

-- 
Ard.




commit e33d2a7b3041d7f8cd1f0a2a4ca42a5bc112b14e
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Aug 31 18:16:45 2020 +0300

    SUNRPC: remove RC4-HMAC-MD5 support from KerberosV

    The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which
    was specifically issued for interoperability with Windows 2000, but was
    never intended to receive the same level of support. The RFC says

      The IETF Kerberos community supports publishing this specification as
      an informational document in order to describe this widely
      implemented technology.  However, while these encryption types
      provide the operations necessary to implement the base Kerberos
      specification [RFC4120], they do not provide all the required
      operations in the Kerberos cryptography framework [RFC3961].  As a
      result, it is not generally possible to implement potential
      extensions to Kerberos using these encryption types.  The Kerberos
      encryption type negotiation mechanism [RFC4537] provides one approach
      for using such extensions even when a Kerberos infrastructure uses
      long-term RC4 keys.  Because this specification does not implement
      operations required by RFC 3961 and because of security concerns with
      the use of RC4 and MD4 discussed in Section 8, this specification is
      not appropriate for publication on the standards track.

      The RC4-HMAC encryption types are used to ease upgrade of existing
      Windows NT environments, provide strong cryptography (128-bit key
      lengths), and provide exportable (meet United States government
      export restriction requirements) encryption.  This document describes
      the implementation of those encryption types.

    Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in
    2018, stating that 'none of the encryption types it specifies should be
    used'

    Note that other outdated algorithms are left in place (some of which are
    guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only
    adversely affect interoperability with Windows NT/2000 systems that have
    not received any updates since 2008 (but are connected to a network
    nonetheless)
    [0] https://tools.ietf.org/html/rfc4757
    [1] https://tools.ietf.org/html/rfc8429

    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Acked-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[toc] | [prev] | [next] | [standalone]

#69772

On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso <carnil@debian.org> wrote:
> >
> > Hi Ard,
> >
> > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote:
> > > Hi Ard,
> > >
> > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > > > L.S.,
> > > >
> > > > This is a request to consider disabling obsolete crypto in 5.10 and
> > > > later Debian builds of the Linux kernel on any architecture.
> > > >
> > > > We are all familiar with the rigid rules when it comes to not breaking
> > > > userspace by making changes to the kernel, but this rule only takes
> > > > effect when anybody notices, and so I am proposing disabling some code
> > > > downstream before removing it entirely.
> > > >
> > > > 5.10 introduces a new Kconfig symbol
> > > >
> > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > > >
> > > > which is enabled by default, but depends on support for the AF_ALG
> > > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > > unlikely to be used anywhere have been made to depend on this new
> > > > symbol.
> > > >
> > > > This means that these obsolete block ciphers will disappear entirely
> > > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > > adding
> > > >
> > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > > >
> > > > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> > > >
> > > > The block ciphers in question are RC4, Khazad, SEED, and
> > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > > to be used via the socket API (although a change was applied to
> > > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > > has already been pulled into bullseye afaik)
> > > >
> > > > Note that this is not a statement on whether these algorithms are
> > > > secure or not -there is simply no point in carrying and shipping code
> > > > that nobody uses or audits, but which can be autoloaded and exercised
> > > > via an unprivileged interface.
> > >
> > > FTR (posteriori), we tried that in
> > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > > (and is in the 5.10.12-1 upload to unstable).
> >
> > There were two reports which might be in the end related to that
> > change:
> >
> > https://bugs.debian.org/979764
> > https://bugs.debian.org/983508
> >
> > We have long that nfs-utils need to be updated, but the version was so
> > outdated, that progress on updating to a newer version stalled, and
> > could not be done in time for bulleye. Once bullseye is released I
> > guess this really needs to be prioritzed in some way.
> >
> > Ard, have you any insight in the above, so, should we revert the above
> > change for bullseye again?
> >
>
> Hello Salvatore,
>
> I think the issue is the patch below. Having something that requires
> RC4 and MD5 for security is an absolute joke in 2021, so I won't
> recommend you reverting it. Instead, you should really fix nfs-utils
> with priority.
>

Any updates on this?

[toc] | [prev] | [next] | [standalone]

#69774

Hi Ard,

On Tue, Mar 09, 2021 at 05:45:01PM +0100, Ard Biesheuvel wrote:
> On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso <carnil@debian.org> wrote:
> > >
> > > Hi Ard,
> > >
> > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote:
> > > > Hi Ard,
> > > >
> > > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > > > > L.S.,
> > > > >
> > > > > This is a request to consider disabling obsolete crypto in 5.10 and
> > > > > later Debian builds of the Linux kernel on any architecture.
> > > > >
> > > > > We are all familiar with the rigid rules when it comes to not breaking
> > > > > userspace by making changes to the kernel, but this rule only takes
> > > > > effect when anybody notices, and so I am proposing disabling some code
> > > > > downstream before removing it entirely.
> > > > >
> > > > > 5.10 introduces a new Kconfig symbol
> > > > >
> > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > > > >
> > > > > which is enabled by default, but depends on support for the AF_ALG
> > > > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > > > unlikely to be used anywhere have been made to depend on this new
> > > > > symbol.
> > > > >
> > > > > This means that these obsolete block ciphers will disappear entirely
> > > > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > > > adding
> > > > >
> > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > > > >
> > > > > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> > > > >
> > > > > The block ciphers in question are RC4, Khazad, SEED, and
> > > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > > > to be used via the socket API (although a change was applied to
> > > > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > > > has already been pulled into bullseye afaik)
> > > > >
> > > > > Note that this is not a statement on whether these algorithms are
> > > > > secure or not -there is simply no point in carrying and shipping code
> > > > > that nobody uses or audits, but which can be autoloaded and exercised
> > > > > via an unprivileged interface.
> > > >
> > > > FTR (posteriori), we tried that in
> > > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > > > (and is in the 5.10.12-1 upload to unstable).
> > >
> > > There were two reports which might be in the end related to that
> > > change:
> > >
> > > https://bugs.debian.org/979764
> > > https://bugs.debian.org/983508
> > >
> > > We have long that nfs-utils need to be updated, but the version was so
> > > outdated, that progress on updating to a newer version stalled, and
> > > could not be done in time for bulleye. Once bullseye is released I
> > > guess this really needs to be prioritzed in some way.
> > >
> > > Ard, have you any insight in the above, so, should we revert the above
> > > change for bullseye again?
> > >
> >
> > Hello Salvatore,
> >
> > I think the issue is the patch below. Having something that requires
> > RC4 and MD5 for security is an absolute joke in 2021, so I won't
> > recommend you reverting it. Instead, you should really fix nfs-utils
> > with priority.
> >
> 
> Any updates on this?

Apologies for not replying earlier. I agree with you.

Debian's nfs-utils situation is quite bad. As you might know we still
ship 1.3.4, which at best is ancient with respect to upstream.  Worse,
we cannot update it at this stage of the freeze (cf.
https://release.debian.org/#release-dates).

So I guess the only two options we have now is either to revert the
above commit you think is the cause of the issues reported, or if this
is feasible apply the needed changes for nfs-utils (if they can be
determined and can be applied to the old version).

After the Debian bullseye release it defintively needs to be a
priority for nfs-utils to be rebased to 2.5.3 and later (and then in
particular keep up with rebasing it, and not fall into the same issue
again).

Salvatore

[toc] | [prev] | [next] | [standalone]

#69776

On Wed, 10 Mar 2021 at 14:38, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi Ard,
>
> On Tue, Mar 09, 2021 at 05:45:01PM +0100, Ard Biesheuvel wrote:
> > On Thu, 25 Feb 2021 at 12:06, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso <carnil@debian.org> wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote:
> > > > > Hi Ard,
> > > > >
> > > > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote:
> > > > > > L.S.,
> > > > > >
> > > > > > This is a request to consider disabling obsolete crypto in 5.10 and
> > > > > > later Debian builds of the Linux kernel on any architecture.
> > > > > >
> > > > > > We are all familiar with the rigid rules when it comes to not breaking
> > > > > > userspace by making changes to the kernel, but this rule only takes
> > > > > > effect when anybody notices, and so I am proposing disabling some code
> > > > > > downstream before removing it entirely.
> > > > > >
> > > > > > 5.10 introduces a new Kconfig symbol
> > > > > >
> > > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE
> > > > > >
> > > > > > which is enabled by default, but depends on support for the AF_ALG
> > > > > > socket API being enabled. In turn, block ciphers that are obsolete and
> > > > > > unlikely to be used anywhere have been made to depend on this new
> > > > > > symbol.
> > > > > >
> > > > > > This means that these obsolete block ciphers will disappear entirely
> > > > > > when the AF_ALG socket API is omitted, but we can get rid of these
> > > > > > block ciphers explicitly too, by not setting the new symbol. I.e.,
> > > > > > adding
> > > > > >
> > > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
> > > > > >
> > > > > > to the kernel configs. Note that Fedora have already done so in release 33 [0]
> > > > > >
> > > > > > The block ciphers in question are RC4, Khazad, SEED, and
> > > > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known
> > > > > > to be used via the socket API (although a change was applied to
> > > > > > iwd/libell recently to get rid of an occurrence of RC4 - this change
> > > > > > has already been pulled into bullseye afaik)
> > > > > >
> > > > > > Note that this is not a statement on whether these algorithms are
> > > > > > secure or not -there is simply no point in carrying and shipping code
> > > > > > that nobody uses or audits, but which can be autoloaded and exercised
> > > > > > via an unprivileged interface.
> > > > >
> > > > > FTR (posteriori), we tried that in
> > > > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737
> > > > > (and is in the 5.10.12-1 upload to unstable).
> > > >
> > > > There were two reports which might be in the end related to that
> > > > change:
> > > >
> > > > https://bugs.debian.org/979764
> > > > https://bugs.debian.org/983508
> > > >
> > > > We have long that nfs-utils need to be updated, but the version was so
> > > > outdated, that progress on updating to a newer version stalled, and
> > > > could not be done in time for bulleye. Once bullseye is released I
> > > > guess this really needs to be prioritzed in some way.
> > > >
> > > > Ard, have you any insight in the above, so, should we revert the above
> > > > change for bullseye again?
> > > >
> > >
> > > Hello Salvatore,
> > >
> > > I think the issue is the patch below. Having something that requires
> > > RC4 and MD5 for security is an absolute joke in 2021, so I won't
> > > recommend you reverting it. Instead, you should really fix nfs-utils
> > > with priority.
> > >
> >
> > Any updates on this?
>
> Apologies for not replying earlier. I agree with you.
>
> Debian's nfs-utils situation is quite bad. As you might know we still
> ship 1.3.4, which at best is ancient with respect to upstream.  Worse,
> we cannot update it at this stage of the freeze (cf.
> https://release.debian.org/#release-dates).
>
> So I guess the only two options we have now is either to revert the
> above commit you think is the cause of the issues reported, or if this
> is feasible apply the needed changes for nfs-utils (if they can be
> determined and can be applied to the old version).
>

Reverting the patch in question in the distro kernel seems reasonable,
but please keep it as a downstream change only. Note that you will
also need to revert the CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE change,
or re-enable the ecb(arc4) driver in another way, because the NFS code
relies on RC4.

> After the Debian bullseye release it defintively needs to be a
> priority for nfs-utils to be rebased to 2.5.3 and later (and then in
> particular keep up with rebasing it, and not fall into the same issue
> again).
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web