mbox series

[0/2] Fix bugs in public_key_verify_signature()

Message ID 20220201003414.55380-1-ebiggers@kernel.org
Headers show
Series Fix bugs in public_key_verify_signature() | expand

Message

Eric Biggers Feb. 1, 2022, 12:34 a.m. UTC
This patchset fixes some bugs in public_key_verify_signature() where it
could be tricked into using the wrong algorithm, as was discussed at
https://lore.kernel.org/linux-integrity/20211202215507.298415-1-zohar@linux.ibm.com/T/#t

I'd appreciate it if the people who care about each of the supported
public key algorithms (RSA, ECDSA, ECRDSA, and SM2) would test this
patchset to make sure it still works for their use case(s).  I've tested
that X.509 and PKCS#7 with RSA still work.

Note, I have *not* included a fix for SM2 being implemented incorrectly.
That is another bug that I pointed out in the above thread.  I think
that bug is for the people who actually care about SM2.

This applies to v5.17-rc2.

Eric Biggers (2):
  KEYS: asymmetric: enforce that sig algo matches key algo
  KEYS: asymmetric: properly validate hash_algo and encoding

 crypto/asymmetric_keys/pkcs7_verify.c    |   6 --
 crypto/asymmetric_keys/public_key.c      | 126 ++++++++++++++++-------
 crypto/asymmetric_keys/x509_public_key.c |   6 --
 3 files changed, 91 insertions(+), 47 deletions(-)


base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c

Comments

tianjia.zhang Feb. 7, 2022, 7:45 a.m. UTC | #1
Hi Eric,

On 2/1/22 8:34 AM, Eric Biggers wrote:
> This patchset fixes some bugs in public_key_verify_signature() where it
> could be tricked into using the wrong algorithm, as was discussed at
> https://lore.kernel.org/linux-integrity/20211202215507.298415-1-zohar@linux.ibm.com/T/#t
> 
> I'd appreciate it if the people who care about each of the supported
> public key algorithms (RSA, ECDSA, ECRDSA, and SM2) would test this
> patchset to make sure it still works for their use case(s).  I've tested
> that X.509 and PKCS#7 with RSA still work.
> 
> Note, I have *not* included a fix for SM2 being implemented incorrectly.
> That is another bug that I pointed out in the above thread.  I think
> that bug is for the people who actually care about SM2.
> 
> This applies to v5.17-rc2.
> 

Sorry for the late reply, thanks for your work.

I did the test and the x509 certificate for SM2-with-SM3 is working
fine.

Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>

Regarding the algorithm information in the signature data used by SM2,
I will add a patch to fix this issue, thanks for pointing it out.

Best regards,
Tianjia

> Eric Biggers (2):
>    KEYS: asymmetric: enforce that sig algo matches key algo
>    KEYS: asymmetric: properly validate hash_algo and encoding
> 
>   crypto/asymmetric_keys/pkcs7_verify.c    |   6 --
>   crypto/asymmetric_keys/public_key.c      | 126 ++++++++++++++++-------
>   crypto/asymmetric_keys/x509_public_key.c |   6 --
>   3 files changed, 91 insertions(+), 47 deletions(-)
> 
> 
> base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c
Jarkko Sakkinen Feb. 21, 2022, 1:46 a.m. UTC | #2
On Mon, Jan 31, 2022 at 04:34:14PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> It is insecure to allow arbitrary hash algorithms and signature
> encodings to be used with arbitrary signature algorithms.  Notably,
> ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't
> disambiguate between different hash algorithms like RSA PKCS#1 v1.5
> padding does.  Therefore, they need to be restricted to certain sets of
> hash algorithms (ideally just one, but in practice small sets are used).
> Additionally, the encoding is an integral part of modern signature
> algorithms, and is not supposed to vary.
> 
> Therefore, tighten the checks of hash_algo and encoding done by
> software_key_determine_akcipher().
> 
> Also rearrange the parameters to software_key_determine_akcipher() to
> put the public_key first, as this is the most important parameter and it
> often determines everything else.
> 
> Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
> Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
> Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  crypto/asymmetric_keys/public_key.c | 111 +++++++++++++++++++---------
>  1 file changed, 76 insertions(+), 35 deletions(-)
> 
> diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
> index aba7113d86c76..a603ee8afdb8d 100644
> --- a/crypto/asymmetric_keys/public_key.c
> +++ b/crypto/asymmetric_keys/public_key.c
> @@ -60,39 +60,83 @@ static void public_key_destroy(void *payload0, void *payload3)
>  }
>  
>  /*
> - * Determine the crypto algorithm name.
> + * Given a public_key, and an encoding and hash_algo to be used for signing
> + * and/or verification with that key, determine the name of the corresponding
> + * akcipher algorithm.  Also check that encoding and hash_algo are allowed.
>   */
> -static
> -int software_key_determine_akcipher(const char *encoding,
> -				    const char *hash_algo,
> -				    const struct public_key *pkey,
> -				    char alg_name[CRYPTO_MAX_ALG_NAME])
> +static int
> +software_key_determine_akcipher(const struct public_key *pkey,
> +				const char *encoding, const char *hash_algo,
> +				char alg_name[CRYPTO_MAX_ALG_NAME])

Why is changing parameter order necessary?

BR, Jarkko
Eric Biggers Feb. 21, 2022, 2:21 a.m. UTC | #3
On Mon, Feb 21, 2022 at 02:46:26AM +0100, Jarkko Sakkinen wrote:
> On Mon, Jan 31, 2022 at 04:34:14PM -0800, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > It is insecure to allow arbitrary hash algorithms and signature
> > encodings to be used with arbitrary signature algorithms.  Notably,
> > ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't
> > disambiguate between different hash algorithms like RSA PKCS#1 v1.5
> > padding does.  Therefore, they need to be restricted to certain sets of
> > hash algorithms (ideally just one, but in practice small sets are used).
> > Additionally, the encoding is an integral part of modern signature
> > algorithms, and is not supposed to vary.
> > 
> > Therefore, tighten the checks of hash_algo and encoding done by
> > software_key_determine_akcipher().
> > 
> > Also rearrange the parameters to software_key_determine_akcipher() to
> > put the public_key first, as this is the most important parameter and it
> > often determines everything else.
> > 
> > Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
> > Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
> > Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> >  crypto/asymmetric_keys/public_key.c | 111 +++++++++++++++++++---------
> >  1 file changed, 76 insertions(+), 35 deletions(-)
> > 
> > diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
> > index aba7113d86c76..a603ee8afdb8d 100644
> > --- a/crypto/asymmetric_keys/public_key.c
> > +++ b/crypto/asymmetric_keys/public_key.c
> > @@ -60,39 +60,83 @@ static void public_key_destroy(void *payload0, void *payload3)
> >  }
> >  
> >  /*
> > - * Determine the crypto algorithm name.
> > + * Given a public_key, and an encoding and hash_algo to be used for signing
> > + * and/or verification with that key, determine the name of the corresponding
> > + * akcipher algorithm.  Also check that encoding and hash_algo are allowed.
> >   */
> > -static
> > -int software_key_determine_akcipher(const char *encoding,
> > -				    const char *hash_algo,
> > -				    const struct public_key *pkey,
> > -				    char alg_name[CRYPTO_MAX_ALG_NAME])
> > +static int
> > +software_key_determine_akcipher(const struct public_key *pkey,
> > +				const char *encoding, const char *hash_algo,
> > +				char alg_name[CRYPTO_MAX_ALG_NAME])
> 
> Why is changing parameter order necessary?
> 

It's mentioned in the commit message.  It's obviously not necessary but this way
makes much more sense IMO.

- Eric