Revert "crypto: pkcs7 - remove sha1 support"
Subsystems (5)
PATCH 1/1 Revert "crypto: pkcs7 - remove sha1 support"
From: Eric Biggers <[email protected]>
This reverts commit 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.
It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.
--- crypto/asymmetric_keys/mscode_parser.c | 3 + crypto/asymmetric_keys/pkcs7_parser.c | 4 ++ crypto/asymmetric_keys/public_key.c | 3 +- crypto/asymmetric_keys/signature.c | 2 +- crypto/asymmetric_keys/x509_cert_parser.c | 8 +++ crypto/testmgr.h | 80 +++++++++++++++++++++++ include/linux/oid_registry.h | 4 ++ kernel/module/Kconfig | 5 ++ 8 files changed, 107 insertions(+), 2 deletions(-)
crypto/asymmetric_keys/mscode_parser.c +3 -0
@@ -73,10 +73,13 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,char buffer[50 ];enum OID oid; oid =look_up_OID (value, vlen);switch (oid) { +case OID_sha1: + ctx->digest_algo ="sha1" ; +break ;case OID_sha256: ctx->digest_algo ="sha256" ;break ;case OID_sha384: ctx->digest_algo ="sha384" ;
crypto/asymmetric_keys/pkcs7_parser.c +4 -0
@@ -225,10 +225,13 @@ int pkcs7_sig_note_digest_algo(void *context, size_t hdrlen, const void *value, size_t vlen) {struct pkcs7_parse_context *ctx = context;switch (ctx->last_oid) { +case OID_sha1: + ctx->sinfo->sig->hash_algo ="sha1" ; +break ;case OID_sha256: ctx->sinfo->sig->hash_algo ="sha256" ;break ;case OID_sha384: ctx->sinfo->sig->hash_algo ="sha384" ;
@@ -276,10 +279,11 @@ int pkcs7_sig_note_pkey_algo(void *context, size_t hdrlen,switch (ctx->last_oid) {case OID_rsaEncryption: ctx->sinfo->sig->pkey_algo ="rsa" ; ctx->sinfo->sig->encoding ="pkcs1" ;break ; +case OID_id_ecdsa_with_sha1:case OID_id_ecdsa_with_sha224:case OID_id_ecdsa_with_sha256:case OID_id_ecdsa_with_sha384:case OID_id_ecdsa_with_sha512:case OID_id_ecdsa_with_sha3_256:
crypto/asymmetric_keys/public_key.c +2 -1
@@ -113,11 +113,12 @@ software_key_determine_akcipher(const struct public_key *pkey,* Unfortunately, in practice ECDSA is used with multiple SHAs, * so we have to allow all of them and not just one. */ if (!hash_algo)return -EINVAL ; - if (strcmp(hash_algo, "sha224") != 0 && + if (strcmp(hash_algo, "sha1") != 0 && + strcmp(hash_algo, "sha224") != 0 && strcmp(hash_algo, "sha256") != 0 && strcmp(hash_algo, "sha384") != 0 && strcmp(hash_algo, "sha512") != 0 && strcmp(hash_algo, "sha3-256") != 0 && strcmp(hash_algo, "sha3-384") != 0 &&
crypto/asymmetric_keys/signature.c +1 -1
@@ -113,11 +113,11 @@ EXPORT_SYMBOL_GPL(decrypt_blob);* @enc: Signature buffer, length params->enc_len * * Sign the specified data blob using the private key specified by params->key. * The signature is wrapped in an encoding if params->encoding is specified * (eg. "pkcs1"). If the encoding needs to know the digest type, this can be -* passed through params->hash_algo (eg. "sha512"). +* passed through params->hash_algo (eg. "sha1"). * * Returns the length of the data placed in the signature buffer or an error. */ int create_signature (struct kernel_pkey_params *params,const void *data,void *enc)
crypto/asymmetric_keys/x509_cert_parser.c +8 -0
@@ -196,10 +196,14 @@ int x509_note_sig_algo(void *context, size_t hdrlen, unsigned char tag,switch (ctx->last_oid) {default :return -ENOPKG ;/* Unsupported combination */ +case OID_sha1WithRSAEncryption: + ctx->cert->sig->hash_algo ="sha1" ; + goto rsa_pkcs1; +case OID_sha256WithRSAEncryption: ctx->cert->sig->hash_algo ="sha256" ; goto rsa_pkcs1;case OID_sha384WithRSAEncryption:
@@ -212,10 +216,14 @@ int x509_note_sig_algo(void *context, size_t hdrlen, unsigned char tag,case OID_sha224WithRSAEncryption: ctx->cert->sig->hash_algo ="sha224" ; goto rsa_pkcs1; +case OID_id_ecdsa_with_sha1: + ctx->cert->sig->hash_algo ="sha1" ; + goto ecdsa; +case OID_id_rsassa_pkcs1_v1_5_with_sha3_256: ctx->cert->sig->hash_algo ="sha3-256" ; goto rsa_pkcs1;case OID_id_rsassa_pkcs1_v1_5_with_sha3_384:
crypto/testmgr.h +80 -0
110 lines not on this page · raw message
include/linux/oid_registry.h +4 -0
@@ -15,21 +15,24 @@* * NOTE! Do not mess with the format of each line as this is read by * build_OID_registry.pl to generate the data for look_up_OID(). */ enum OID { + OID_id_dsa_with_sha1,/* 1.2.840.10030.4.3 */ OID_id_dsa,/* 1.2.840.10040.4.1 */ OID_id_ecPublicKey,/* 1.2.840.10045.2.1 */ OID_id_prime192v1,/* 1.2.840.10045.3.1.1 */ OID_id_prime256v1,/* 1.2.840.10045.3.1.7 */ + OID_id_ecdsa_with_sha1,/* 1.2.840.10045.4.1 */ OID_id_ecdsa_with_sha224,/* 1.2.840.10045.4.3.1 */ OID_id_ecdsa_with_sha256,/* 1.2.840.10045.4.3.2 */ OID_id_ecdsa_with_sha384,/* 1.2.840.10045.4.3.3 */ OID_id_ecdsa_with_sha512,/* 1.2.840.10045.4.3.4 */ /* PKCS#1 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)} */ OID_rsaEncryption,/* 1.2.840.113549.1.1.1 */ + OID_sha1WithRSAEncryption,/* 1.2.840.113549.1.1.5 */ OID_sha256WithRSAEncryption,/* 1.2.840.113549.1.1.11 */ OID_sha384WithRSAEncryption,/* 1.2.840.113549.1.1.12 */ OID_sha512WithRSAEncryption,/* 1.2.840.113549.1.1.13 */ OID_sha224WithRSAEncryption,/* 1.2.840.113549.1.1.14 */ /* PKCS#7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7)} */
@@ -62,10 +65,11 @@ enum OID { OID_IAKerb,/* 1.3.6.1.5.2.5 */ OID_PKU2U ,/* 1.3.5.1.5.2.7 */ OID_Scram,/* 1.3.6.1.5.5.14 */ OID_certAuthInfoAccess,/* 1.3.6.1.5.5.7.1.1 */ + OID_sha1,/* 1.3.14.3.2.26 */ OID_id_ansip384r1,/* 1.3.132.0.34 */ OID_sha256,/* 2.16.840.1.101.3.4.2.1 */ OID_sha384,/* 2.16.840.1.101.3.4.2.2 */ OID_sha512,/* 2.16.840.1.101.3.4.2.3 */ OID_sha224, /* 2.16.840.1.101.3.4.2.4 */
kernel/module/Kconfig +5 -0
@@ -234,10 +234,14 @@ choice signature generation. This algorithm _must_ be built into the kernel directly so that signature verification can take place. It is not possible to load a signed module containing the algorithm to check the signature on that module. +config MODULE_SIG_SHA1 + bool "Sign modules with SHA-1" + select CRYPTO_SHA1 + config MODULE_SIG_SHA256 bool "Sign modules with SHA-256" select CRYPTO_SHA256 config MODULE_SIG_SHA384
@@ -263,10 +267,11 @@ config MODULE_SIG_SHA3_512 endchoice config MODULE_SIG_HASH string depends on MODULE_SIG || IMA_APPRAISE_MODSIG + default "sha1" if MODULE_SIG_SHA1 default "sha256" if MODULE_SIG_SHA256 default "sha384" if MODULE_SIG_SHA384 default "sha512" if MODULE_SIG_SHA512 default "sha3-256" if MODULE_SIG_SHA3_256 default "sha3-384" if MODULE_SIG_SHA3_384
base-commit: 259f7d5e2baf87fcbb4fabc46526c9c47fed1914
Signature · 1 line
2.44.0
Eric,
Eric Biggers, 2024-03-13T16:32:27-07:00:
Quoted 10 lines
From: Eric Biggers <[email protected]>
This reverts commit
16ab7cb5825fc3425c16ad2c6e53d827f382d7c6because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.
Quoted 8 lines
It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of
MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.Reported-by Karel Balej <[email protected]>Cc Dimitri John Ledkov <[email protected]>Signed-off-by Eric Biggers <[email protected]>
thank you very much for the revert. I have compiled 6.8 with this patch and attest that it solves my eduroam connection issue.
May I please ask, though, why you did not Cc stable (and add a Fixes trailer for that matter)? It seems like something that would be nice to see fixed in 6.7.y and 6.8.y too as soon as possible.
Kind regards,
K. B.
Quoted 22 lines · Karel Balej
Eric,
Eric Biggers, 2024-03-13T16:32:27-07:00:
Quoted 10 lines
From: Eric Biggers <[email protected]>
This reverts commit
16ab7cb5825fc3425c16ad2c6e53d827f382d7c6because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.Quoted 8 lines
It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of
MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.Reported-by Karel Balej <[email protected]>Cc Dimitri John Ledkov <[email protected]>Signed-off-by Eric Biggers <[email protected]>
Quoted 8 lines
thank you very much for the revert. I have compiled 6.8 with this patch and attest that it solves my eduroam connection issue.
Tested-by Karel Balej <[email protected]>May I please ask, though, why you did not Cc stable (and add a Fixes trailer for that matter)? It seems like something that would be nice to see fixed in 6.7.y and 6.8.y too as soon as possible.
I just forgot. Reverts usually get backported without asking anyway, but the following should be added to make it explicit:
Fixes: 16ab7cb5825f ("crypto: pkcs7 - remove sha1 support")
Cc: [email protected]That should just be added when the patch is applied, unless I happen to need to send out a new version anyway.
We need to decide who is actually going to apply this revert. Probably Herbert, since he took the commit that's being reverted?
- Eric
Jarkko Sakkinen
maintainerQuoted 34 lines · Eric Biggers
From: Eric Biggers <[email protected]>
This reverts commit
16ab7cb5825fc3425c16ad2c6e53d827f382d7c6because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of
MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.Reported-by Karel Balej <[email protected]>Cc Dimitri John Ledkov <[email protected]>Signed-off-by Eric Biggers <[email protected]>--- crypto/asymmetric_keys/mscode_parser.c | 3 + crypto/asymmetric_keys/pkcs7_parser.c | 4 ++ crypto/asymmetric_keys/public_key.c | 3 +- crypto/asymmetric_keys/signature.c | 2 +- crypto/asymmetric_keys/x509_cert_parser.c | 8 +++ crypto/testmgr.h | 80 +++++++++++++++++++++++ include/linux/oid_registry.h | 4 ++ kernel/module/Kconfig | 5 ++ 8 files changed, 107 insertions(+), 2 deletions(-)crypto/asymmetric_keys/mscode_parser.c +0
-0
crypto/asymmetric_keys/mscode_parser.c int mscode_note_digest_algo(void *context, size_t hdrlen, · line 80
Quoted 8 lines
crypto/asymmetric_keys/mscode_parser.c +3
-0@@ -73,10 +73,13 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,char buffer[50 ];enum OID oid; oid =look_up_OID (value, vlen);switch (oid) { +case OID_sha1: + ctx->digest_algo ="sha1" ; +break ;
I fully agree with the change BUT...
IMHO it would make sense to e.g either add inline comment about iwd dependency or link to the bug report here.
I'd like to think that there is common will to eventually get rid of all of SHA-1, and thus in cases where it is not yet possible it would make sense to guide what to needs to be done to make it happen, right?
BR, Jarkko
Quoted 16 lines · Jarkko Sakkinen
crypto/asymmetric_keys/mscode_parser.c int mscode_note_digest_algo(void *context, size_t hdrlen, · line 80
Quoted 13 lines
crypto/asymmetric_keys/mscode_parser.c +3
-0@@ -73,10 +73,13 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,char buffer[50 ];enum OID oid; oid =look_up_OID (value, vlen);switch (oid) { +case OID_sha1: + ctx->digest_algo ="sha1" ; +break ;I fully agree with the change BUT...
Quoted 8 lines
IMHO it would make sense to e.g either add inline comment about iwd dependency or link to the bug report here.
I'd like to think that there is common will to eventually get rid of all of SHA-1, and thus in cases where it is not yet possible it would make sense to guide what to needs to be done to make it happen, right?
BR, Jarkko
This is supposed to just be a revert, so it's best not to mess around with adding additional stuff that wasn't in the original commit. The sha1 signatures are also not unique; iwd is also forcing the kernel to keep supporting MD4, RC4, KEYCTL_DH_COMPUTE, KEYCTL_PKEY_{QUERY,ENCRYPT,DECRYPT,SIGN,VERIFY}, etc. Probably more than I don't know about. I guess all of this should be documented in the code in appropriate places. Probably the iwd folks should step in to do this, as they know best what they're using and they got a lot of this added to the kernel in the first place.
- Eric
Quoted 7 lines · Eric Biggers
Quoted 5 lines · Jarkko Sakkinen
I'd like to think that there is common will to eventually get rid of all of SHA-1, and thus in cases where it is not yet possible it would make sense to guide what to needs to be done to make it happen, right?
BR, Jarkko
Quoted 8 lines
This is supposed to just be a revert, so it's best not to mess around with adding additional stuff that wasn't in the original commit. The sha1 signatures are also not unique; iwd is also forcing the kernel to keep supporting MD4, RC4,
KEYCTL_DH_COMPUTE, KEYCTL_PKEY_{QUERY,ENCRYPT,DECRYPT,SIGN,VERIFY}, etc. Probably more than I don't know about. I guess all of this should be documented in the code in appropriate places. Probably the iwd folks should step in to do this, as they know best what they're using and they got a lot of this added to the kernel in the first place.
As far as I know none of these were added specifically for iwd but I could be wrong. RC4 is not in the kernel anymore.
With regards to SHA1 it is used by iwd directly through an API but more importantly it's a dependency for x509 support in practice. Outside of module signing most x509 certificates in the wild use SHA1:
wifi, https. This thread originally talked about the removal of SHA1 access through some API, not SHA1 in general.
Regarding the use of the kernel crypto in iwd, IIRC some of the motivation was:
* to avoid duplication. On a small system it's hard to justify having the same algorithms in the kernel and in userspace. openssl is probably larger than all of ell+iwd.
* (various arguments can be made about how duplication doesn't help security, but an argument can be made the other way as well)
* there is (was?) a plan to use the kernel keys API to abstract passing keys/keyrings between processes to greatly reduce the presence of the actual key contents in memory/filesystem. Network Manager could load a key from file or a PKCS11 device and pass its kernel handle to iwd or other userspace instead of file paths, with the files necessarily being readable by multiple processes and loaded multiple times into memory. The keys could also be loaded once on boot. Or the keys could be in TPM and never be seen in main memory, only their API handles.
Best regards
Jarkko Sakkinen
maintainerQuoted 35 lines · Eric Biggers
Quoted 16 lines · Jarkko Sakkinen
crypto/asymmetric_keys/mscode_parser.c int mscode_note_digest_algo(void *context, size_t hdrlen, · line 80
Quoted 13 lines
crypto/asymmetric_keys/mscode_parser.c +3
-0@@ -73,10 +73,13 @@ int mscode_note_digest_algo(void *context, size_t hdrlen,char buffer[50 ];enum OID oid; oid =look_up_OID (value, vlen);switch (oid) { +case OID_sha1: + ctx->digest_algo ="sha1" ; +break ;I fully agree with the change BUT...
Quoted 8 lines
IMHO it would make sense to e.g either add inline comment about iwd dependency or link to the bug report here.
I'd like to think that there is common will to eventually get rid of all of SHA-1, and thus in cases where it is not yet possible it would make sense to guide what to needs to be done to make it happen, right?
BR, Jarkko
This is supposed to just be a revert, so it's best not to mess around with adding additional stuff that wasn't in the original commit. The sha1 signatures are also not unique; iwd is also forcing the kernel to keep supporting MD4, RC4,
KEYCTL_DH_COMPUTE, KEYCTL_PKEY_{QUERY,ENCRYPT,DECRYPT,SIGN,VERIFY}, etc. Probably more than I don't know about. I guess all of this should be documented in the code in appropriate places. Probably the iwd folks should step in to do this, as they know best what they're using and they got a lot of this added to the kernel in the first place.
Quoted 1 line
- Eric
OK, fair point.
BR, Jarkko
Herbert Xu
maintainerQuoted 18 lines · Eric Biggers
From: Eric Biggers <[email protected]>
This reverts commit
16ab7cb5825fc3425c16ad2c6e53d827f382d7c6because it broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell, and apparently it is relying on SHA-1 signature support. These UAPIs are fairly obscure, and their documentation does not mention which algorithms they support. iwd really should be using a properly supported userspace crypto library instead. Regardless, since something broke we have to revert the change.It may be possible that some parts of this commit can be reinstated without breaking iwd (e.g. probably the removal of
MODULE_SIG_SHA1), but for now this just does a full revert to get things working again.Reported-by Karel Balej <[email protected]>Cc Dimitri John Ledkov <[email protected]>Signed-off-by Eric Biggers <[email protected]>
Quoted 10 lines
--- crypto/asymmetric_keys/mscode_parser.c | 3 + crypto/asymmetric_keys/pkcs7_parser.c | 4 ++ crypto/asymmetric_keys/public_key.c | 3 +- crypto/asymmetric_keys/signature.c | 2 +- crypto/asymmetric_keys/x509_cert_parser.c | 8 +++ crypto/testmgr.h | 80 +++++++++++++++++++++++ include/linux/oid_registry.h | 4 ++ kernel/module/Kconfig | 5 ++ 8 files changed, 107 insertions(+), 2 deletions(-)
Patch applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt