From: Eric Biggers <ebiggers3@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
Michael Halcrow <mhalcrow@google.com>,
Eric Biggers <ebiggers@google.com>,
Paolo Valente <paolo.valente@linaro.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported
Date: Tue, 20 Feb 2018 22:34:32 +0000 [thread overview]
Message-ID: <20180220223432.GE70958@gmail.com> (raw)
In-Reply-To: <16536.1518102450@warthog.procyon.org.uk>
Hi David,
On Thu, Feb 08, 2018 at 03:07:30PM +0000, David Howells wrote:
> Eric Biggers <ebiggers3@gmail.com> wrote:
>
> > The X.509 parser mishandles the case where the certificate's signature's
> > hash algorithm is not available in the crypto API. In this case,
> > x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this
> > part seems to be intentional.
>
> Well, yes, that would be intentional: we can't digest the digestibles without
> access to a hash algorithm to do so and we can't allocate a digest buffer
> without knowing how big it should be.
>
> > Fix this by making public_key_verify_signature() return -ENOPKG if the
> > hash buffer has not been allocated.
>
> Hmmm... I'm not sure that this is the right place to do this, since it
> obscures a potential invalid argument within the kernel.
>
> I'm more inclined that the users of X.509 certs should check
> x509->unsupported_sig (pkcs7_verify_sig_chain() does this already partially).
>
Well, either way using BUG_ON() is inappropriate for recoverable problems where
an error code can be returned. In this case we can simply indicate that the
signature verification failed. Note that unprivileged users can reach this
BUG_ON(), and it also appears to be reachable in at least 3 different ways...
So it really has to be fixed.
And considering that the ->unsupported_sig and ->unsupported_key flags are
almost completely broken anyway, it sounds like there would have to be a second
patchset to actually fix them. So I'd rather you just took the more important
fixes in patches 1-5 now as-is, and then a patchset to make certificates with
unsupported algorithms be accepted in more cases can be done separately.
Thanks,
Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
Michael Halcrow <mhalcrow@google.com>,
Eric Biggers <ebiggers@google.com>,
Paolo Valente <paolo.valente@linaro.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported
Date: Tue, 20 Feb 2018 14:34:32 -0800 [thread overview]
Message-ID: <20180220223432.GE70958@gmail.com> (raw)
In-Reply-To: <16536.1518102450@warthog.procyon.org.uk>
Hi David,
On Thu, Feb 08, 2018 at 03:07:30PM +0000, David Howells wrote:
> Eric Biggers <ebiggers3@gmail.com> wrote:
>
> > The X.509 parser mishandles the case where the certificate's signature's
> > hash algorithm is not available in the crypto API. In this case,
> > x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this
> > part seems to be intentional.
>
> Well, yes, that would be intentional: we can't digest the digestibles without
> access to a hash algorithm to do so and we can't allocate a digest buffer
> without knowing how big it should be.
>
> > Fix this by making public_key_verify_signature() return -ENOPKG if the
> > hash buffer has not been allocated.
>
> Hmmm... I'm not sure that this is the right place to do this, since it
> obscures a potential invalid argument within the kernel.
>
> I'm more inclined that the users of X.509 certs should check
> x509->unsupported_sig (pkcs7_verify_sig_chain() does this already partially).
>
Well, either way using BUG_ON() is inappropriate for recoverable problems where
an error code can be returned. In this case we can simply indicate that the
signature verification failed. Note that unprivileged users can reach this
BUG_ON(), and it also appears to be reachable in at least 3 different ways...
So it really has to be fixed.
And considering that the ->unsupported_sig and ->unsupported_key flags are
almost completely broken anyway, it sounds like there would have to be a second
patchset to actually fix them. So I'd rather you just took the more important
fixes in patches 1-5 now as-is, and then a patchset to make certificates with
unsupported algorithms be accepted in more cases can be done separately.
Thanks,
Eric
next prev parent reply other threads:[~2018-02-20 22:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 1:10 [PATCH 0/9] PKCS#7 / X.509 fixes and cleanups Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 1/9] PKCS#7: fix certificate chain verification Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 2/9] PKCS#7: fix certificate blacklisting Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 3/9] PKCS#7: fix direct verification of SignerInfo signature Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-08 15:07 ` David Howells
2018-02-20 22:34 ` Eric Biggers [this message]
2018-02-20 22:34 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 5/9] X.509: fix NULL dereference when restricting key with unsupported_sig Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 6/9] PKCS#7: remove unnecessary check for NULL sinfo->sig->hash_algo Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-08 15:13 ` David Howells
2018-02-07 1:10 ` [PATCH 7/9] X.509: remove never-set ->unsupported_key flag Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-07 1:10 ` [PATCH 8/9] X.509: remove dead code that set ->unsupported_sig Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-08 15:27 ` David Howells
2018-02-07 1:10 ` [PATCH 9/9] X.509: self_signed implies !unsupported_sig Eric Biggers
2018-02-07 1:10 ` Eric Biggers
2018-02-08 14:28 ` [PATCH 0/9] PKCS#7 / X.509 fixes and cleanups David Howells
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180220223432.GE70958@gmail.com \
--to=ebiggers3@gmail.com \
--cc=dhowells@redhat.com \
--cc=ebiggers@google.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=paolo.valente@linaro.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.