Bug 215750 - Perhaps reasonable to remove hash option CONFIG_MODULE_SIG_SHA1
Summary: Perhaps reasonable to remove hash option CONFIG_MODULE_SIG_SHA1
Status: REOPENED
Alias: None
Product: Tools
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Tools.Other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-27 01:54 UTC by Dennis Clarke
Modified: 2022-03-27 17:10 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.17.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Dennis Clarke 2022-03-27 01:54:26 UTC
I am not sure what component that would apply to. However I almost
always build a kernel with modules that are signed using the sign-file.c
tool within /scripts and follow the CA cert documentation that is well
described in Documentation/admin-guide/module-signing.rst.

This generally means CONFIG_MODULE_SIG_FORCE is in place along with the
CONFIG_MODULE_SIG_ALL option which does wonders during module install.

The question : Which hash algorithm should modules be signed with?

There are five options neatly documented thus : 

    This presents a choice of which hash algorithm the installation
    phase will sign the modules with:

        CONFIG_MODULE_SIG_SHA1    Sign modules with SHA-1
        CONFIG_MODULE_SIG_SHA224  Sign modules with SHA-224
        CONFIG_MODULE_SIG_SHA256  Sign modules with SHA-256
        CONFIG_MODULE_SIG_SHA384  Sign modules with SHA-384
        CONFIG_MODULE_SIG_SHA512  Sign modules with SHA-512

    The algorithm selected here will also be built into the kernel
    (rather than being a module) so that modules signed with that
    algorithm can have their signatures checked without causing a
    dependency loop.

I may be a bit of a nit pick here by suggesting that SHA-1 be retired
from that list. In order to justify such an idea it seems that I would
need to create a kernel module with a SHA1 hash collision or similar
deep magic. Not a trivial wave of the hand to do such a feat. 

In any case this may not even be a valid bug and it is more like a RFE
type idea. 



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 1 Artem S. Tashkinov 2022-03-27 13:11:25 UTC
Distros won't use SHA1 anyways.

As a user who builds their own kernel you couldn't care less anyways for a multitude of reasons (no one outside your system will know your private keys anyways and if they somehow get root access no signatures will not save you).

Is this such an eye sore for you? If it is, you could find the appropriate subsystem maintainer and send a patch.
Comment 2 Dennis Clarke 2022-03-27 15:58:16 UTC
(In reply to Artem S. Tashkinov from comment #1)
> Distros won't use SHA1 anyways.
> 
> As a user who builds their own kernel you couldn't care less anyways for a
> multitude of reasons (no one outside your system will know your private keys
> anyways and if they somehow get root access no signatures will not save you).
> 
> Is this such an eye sore for you? If it is, you could find the appropriate
> subsystem maintainer and send a patch.

Sorry but I was motivated by the update from the OpenSSH folks who
have this to say : 


  OpenSSH 8.8 includes a number of changes that may affect existing
  configurations:

   * This release disables RSA signatures using the SHA-1 hash algorithm
     by default. This change has been made as the SHA-1 hash algorithm
     is cryptographically broken, and it is possible to create 
     chosen-prefix hash collisions for <USD$50K.


Not my words. In general the SHA1 hash algorithm is not being used in
anything of value anymore.  At the very least it *should* not be. Your
argument is weak and I would suggest that the SHA1 hash algorithm no 
longer be offered in the Linux kernel build process. 

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 3 Dennis Clarke 2022-03-27 16:05:44 UTC
> find the appropriate subsystem maintainer and send a patch.

Now that *is* a good idea. I shall delve in.

Leave the bug report open please.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 4 Dennis Clarke 2022-03-27 17:08:22 UTC
The problem seems to be with scripts/sign-file.c where an old
version of OpenSSL may be detected and that enforces the SHA1
hash algorithm : 

000031
000032  /*
000033   * Use CMS if we have openssl-1.0.0 or newer available - otherwise we have to
000034   * assume that it's not available and its header file is missing and that we
000035   * should use PKCS#7 instead.  Switching to the older PKCS#7 format restricts
000036   * the options we have on specifying the X.509 certificate we want.
000037   *
000038   * Further, older versions of OpenSSL don't support manually adding signers to
000039   * the PKCS#7 message so have to accept that we get a certificate included in
000040   * the signature message.  Nor do such older versions of OpenSSL support
000041   * signing with anything other than SHA1 - so we're stuck with that if such is
000042   * the case.
000043   */
000044  #if defined(LIBRESSL_VERSION_NUMBER) || \
000045          OPENSSL_VERSION_NUMBER < 0x10000000L || \
000046          defined(OPENSSL_NO_CMS)
000047  #define USE_PKCS7
000048  #endif
000049  #ifndef USE_PKCS7
000050  #include <openssl/cms.h>
000051  #else
000052  #include <openssl/pkcs7.h>
000053  #endif
000054


Later we see : 


000281  #ifdef USE_PKCS7
000282          if (strcmp(hash_algo, "sha1") != 0) {
000283                  fprintf(stderr, "sign-file: %s only supports SHA1 signing\n",
000284                          OPENSSL_VERSION_TEXT);
000285                  exit(3);
000286          }
000287  #endif


    That pretty much slams the kernel module signing process into a SHA1
hash algorithm as well as the old methods and mechanisms described in
RFC 2315 from 1998.  The Cryptographic Message Syntax (CMS) as we see in
new RFC 5652 is now impossible.

Note You need to log in before you can comment on or make changes to this bug.