2019-05-20 17:08:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2014-07-01 15:40:19 +00:00
|
|
|
/* Verify the signature on a PKCS#7 message.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) "PKCS7: "fmt
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/asn1.h>
|
|
|
|
#include <crypto/hash.h>
|
2019-06-28 02:19:26 +00:00
|
|
|
#include <crypto/hash_info.h>
|
2016-02-02 18:08:53 +00:00
|
|
|
#include <crypto/public_key.h>
|
2014-07-01 15:40:19 +00:00
|
|
|
#include "pkcs7_parser.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Digest the relevant parts of the PKCS#7 data
|
|
|
|
*/
|
|
|
|
static int pkcs7_digest(struct pkcs7_message *pkcs7,
|
|
|
|
struct pkcs7_signed_info *sinfo)
|
|
|
|
{
|
2016-04-06 15:13:33 +00:00
|
|
|
struct public_key_signature *sig = sinfo->sig;
|
2014-07-01 15:40:19 +00:00
|
|
|
struct crypto_shash *tfm;
|
|
|
|
struct shash_desc *desc;
|
2016-04-06 15:13:33 +00:00
|
|
|
size_t desc_size;
|
2014-07-01 15:40:19 +00:00
|
|
|
int ret;
|
|
|
|
|
2016-04-06 15:13:33 +00:00
|
|
|
kenter(",%u,%s", sinfo->index, sinfo->sig->hash_algo);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
2019-06-28 02:19:26 +00:00
|
|
|
/* The digest was calculated already. */
|
|
|
|
if (sig->digest)
|
|
|
|
return 0;
|
|
|
|
|
2016-04-06 15:13:33 +00:00
|
|
|
if (!sinfo->sig->hash_algo)
|
2014-07-01 15:40:19 +00:00
|
|
|
return -ENOPKG;
|
|
|
|
|
|
|
|
/* Allocate the hashing algorithm we're going to need and find out how
|
|
|
|
* big the hash operational data will be.
|
|
|
|
*/
|
2016-04-06 15:13:33 +00:00
|
|
|
tfm = crypto_alloc_shash(sinfo->sig->hash_algo, 0, 0);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (IS_ERR(tfm))
|
|
|
|
return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
|
|
|
|
|
|
|
|
desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
|
2016-04-06 15:13:33 +00:00
|
|
|
sig->digest_size = crypto_shash_digestsize(tfm);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
|
|
|
ret = -ENOMEM;
|
2016-04-06 15:13:33 +00:00
|
|
|
sig->digest = kmalloc(sig->digest_size, GFP_KERNEL);
|
|
|
|
if (!sig->digest)
|
|
|
|
goto error_no_desc;
|
|
|
|
|
|
|
|
desc = kzalloc(desc_size, GFP_KERNEL);
|
|
|
|
if (!desc)
|
2014-07-01 15:40:19 +00:00
|
|
|
goto error_no_desc;
|
|
|
|
|
|
|
|
desc->tfm = tfm;
|
|
|
|
|
|
|
|
/* Digest the message [RFC2315 9.3] */
|
2017-12-08 15:13:28 +00:00
|
|
|
ret = crypto_shash_digest(desc, pkcs7->data, pkcs7->data_len,
|
|
|
|
sig->digest);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
2016-04-06 15:13:33 +00:00
|
|
|
pr_devel("MsgDigest = [%*ph]\n", 8, sig->digest);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
|
|
|
/* However, if there are authenticated attributes, there must be a
|
|
|
|
* message digest attribute amongst them which corresponds to the
|
|
|
|
* digest we just calculated.
|
|
|
|
*/
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
if (sinfo->authattrs) {
|
2014-07-01 15:40:19 +00:00
|
|
|
u8 tag;
|
|
|
|
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
if (!sinfo->msgdigest) {
|
|
|
|
pr_warn("Sig %u: No messageDigest\n", sinfo->index);
|
|
|
|
ret = -EKEYREJECTED;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2016-04-06 15:13:33 +00:00
|
|
|
if (sinfo->msgdigest_len != sig->digest_size) {
|
2014-07-01 15:40:19 +00:00
|
|
|
pr_debug("Sig %u: Invalid digest size (%u)\n",
|
|
|
|
sinfo->index, sinfo->msgdigest_len);
|
|
|
|
ret = -EBADMSG;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2016-04-06 15:13:33 +00:00
|
|
|
if (memcmp(sig->digest, sinfo->msgdigest,
|
|
|
|
sinfo->msgdigest_len) != 0) {
|
2014-07-01 15:40:19 +00:00
|
|
|
pr_debug("Sig %u: Message digest doesn't match\n",
|
|
|
|
sinfo->index);
|
|
|
|
ret = -EKEYREJECTED;
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We then calculate anew, using the authenticated attributes
|
|
|
|
* as the contents of the digest instead. Note that we need to
|
|
|
|
* convert the attributes from a CONT.0 into a SET before we
|
|
|
|
* hash it.
|
|
|
|
*/
|
2016-04-06 15:13:33 +00:00
|
|
|
memset(sig->digest, 0, sig->digest_size);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
|
|
|
ret = crypto_shash_init(desc);
|
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
|
|
|
tag = ASN1_CONS_BIT | ASN1_SET;
|
|
|
|
ret = crypto_shash_update(desc, &tag, 1);
|
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
|
|
|
ret = crypto_shash_finup(desc, sinfo->authattrs,
|
2016-04-06 15:13:33 +00:00
|
|
|
sinfo->authattrs_len, sig->digest);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (ret < 0)
|
|
|
|
goto error;
|
2016-04-06 15:13:33 +00:00
|
|
|
pr_devel("AADigest = [%*ph]\n", 8, sig->digest);
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
error:
|
2016-04-06 15:13:33 +00:00
|
|
|
kfree(desc);
|
2014-07-01 15:40:19 +00:00
|
|
|
error_no_desc:
|
|
|
|
crypto_free_shash(tfm);
|
|
|
|
kleave(" = %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-06-28 02:19:26 +00:00
|
|
|
int pkcs7_get_digest(struct pkcs7_message *pkcs7, const u8 **buf, u32 *len,
|
|
|
|
enum hash_algo *hash_algo)
|
|
|
|
{
|
|
|
|
struct pkcs7_signed_info *sinfo = pkcs7->signed_infos;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function doesn't support messages with more than one signature.
|
|
|
|
*/
|
|
|
|
if (sinfo == NULL || sinfo->next != NULL)
|
|
|
|
return -EBADMSG;
|
|
|
|
|
|
|
|
ret = pkcs7_digest(pkcs7, sinfo);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
*buf = sinfo->sig->digest;
|
|
|
|
*len = sinfo->sig->digest_size;
|
|
|
|
|
2020-09-02 14:07:17 +00:00
|
|
|
i = match_string(hash_algo_name, HASH_ALGO__LAST,
|
|
|
|
sinfo->sig->hash_algo);
|
|
|
|
if (i >= 0)
|
|
|
|
*hash_algo = i;
|
2019-06-28 02:19:26 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
/*
|
2014-07-01 15:40:19 +00:00
|
|
|
* Find the key (X.509 certificate) to use to verify a PKCS#7 message. PKCS#7
|
|
|
|
* uses the issuer's name and the issuing certificate serial number for
|
|
|
|
* matching purposes. These must match the certificate issuer's name (not
|
|
|
|
* subject's name) and the certificate serial number [RFC 2315 6.7].
|
|
|
|
*/
|
|
|
|
static int pkcs7_find_key(struct pkcs7_message *pkcs7,
|
|
|
|
struct pkcs7_signed_info *sinfo)
|
|
|
|
{
|
|
|
|
struct x509_certificate *x509;
|
|
|
|
unsigned certix = 1;
|
|
|
|
|
2014-09-16 16:36:13 +00:00
|
|
|
kenter("%u", sinfo->index);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
|
|
|
for (x509 = pkcs7->certs; x509; x509 = x509->next, certix++) {
|
|
|
|
/* I'm _assuming_ that the generator of the PKCS#7 message will
|
|
|
|
* encode the fields from the X.509 cert in the same way in the
|
|
|
|
* PKCS#7 message - but I can't be 100% sure of that. It's
|
|
|
|
* possible this will need element-by-element comparison.
|
|
|
|
*/
|
2016-04-06 15:13:33 +00:00
|
|
|
if (!asymmetric_key_id_same(x509->id, sinfo->sig->auth_ids[0]))
|
2014-07-01 15:40:19 +00:00
|
|
|
continue;
|
|
|
|
pr_devel("Sig %u: Found cert serial match X.509[%u]\n",
|
|
|
|
sinfo->index, certix);
|
|
|
|
|
|
|
|
sinfo->signer = x509;
|
|
|
|
return 0;
|
|
|
|
}
|
2014-09-16 16:36:13 +00:00
|
|
|
|
2014-09-16 16:36:17 +00:00
|
|
|
/* The relevant X.509 cert isn't found here, but it might be found in
|
|
|
|
* the trust keyring.
|
|
|
|
*/
|
|
|
|
pr_debug("Sig %u: Issuing X.509 cert not found (#%*phN)\n",
|
|
|
|
sinfo->index,
|
2016-04-06 15:13:33 +00:00
|
|
|
sinfo->sig->auth_ids[0]->len, sinfo->sig->auth_ids[0]->data);
|
2014-09-16 16:36:17 +00:00
|
|
|
return 0;
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
/*
|
|
|
|
* Verify the internal certificate chain as best we can.
|
|
|
|
*/
|
|
|
|
static int pkcs7_verify_sig_chain(struct pkcs7_message *pkcs7,
|
|
|
|
struct pkcs7_signed_info *sinfo)
|
|
|
|
{
|
2016-04-06 15:13:33 +00:00
|
|
|
struct public_key_signature *sig;
|
2014-07-01 15:40:19 +00:00
|
|
|
struct x509_certificate *x509 = sinfo->signer, *p;
|
2015-07-20 20:16:26 +00:00
|
|
|
struct asymmetric_key_id *auth;
|
2014-07-01 15:40:19 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
kenter("");
|
|
|
|
|
|
|
|
for (p = pkcs7->certs; p; p = p->next)
|
|
|
|
p->seen = false;
|
|
|
|
|
|
|
|
for (;;) {
|
2014-09-16 16:36:13 +00:00
|
|
|
pr_debug("verify %s: %*phN\n",
|
|
|
|
x509->subject,
|
|
|
|
x509->raw_serial_size, x509->raw_serial);
|
2014-07-01 15:40:19 +00:00
|
|
|
x509->seen = true;
|
2017-04-03 15:07:25 +00:00
|
|
|
|
|
|
|
if (x509->blacklisted) {
|
|
|
|
/* If this cert is blacklisted, then mark everything
|
|
|
|
* that depends on this as blacklisted too.
|
|
|
|
*/
|
|
|
|
sinfo->blacklisted = true;
|
|
|
|
for (p = sinfo->signer; p != x509; p = p->signer)
|
|
|
|
p->blacklisted = true;
|
|
|
|
pr_debug("- blacklisted\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-31 13:46:44 +00:00
|
|
|
pr_debug("- issuer %s\n", x509->issuer);
|
2016-04-06 15:13:33 +00:00
|
|
|
sig = x509->sig;
|
|
|
|
if (sig->auth_ids[0])
|
2015-07-20 20:16:26 +00:00
|
|
|
pr_debug("- authkeyid.id %*phN\n",
|
2016-04-06 15:13:33 +00:00
|
|
|
sig->auth_ids[0]->len, sig->auth_ids[0]->data);
|
|
|
|
if (sig->auth_ids[1])
|
2015-07-20 20:16:26 +00:00
|
|
|
pr_debug("- authkeyid.skid %*phN\n",
|
2016-04-06 15:13:33 +00:00
|
|
|
sig->auth_ids[1]->len, sig->auth_ids[1]->data);
|
2014-07-01 15:40:19 +00:00
|
|
|
|
2016-04-06 15:13:34 +00:00
|
|
|
if (x509->self_signed) {
|
2014-07-01 15:40:19 +00:00
|
|
|
/* If there's no authority certificate specified, then
|
|
|
|
* the certificate must be self-signed and is the root
|
|
|
|
* of the chain. Likewise if the cert is its own
|
|
|
|
* authority.
|
|
|
|
*/
|
2016-04-06 15:13:34 +00:00
|
|
|
if (x509->unsupported_sig)
|
2022-01-19 00:54:35 +00:00
|
|
|
goto unsupported_sig_in_x509;
|
2014-07-01 15:40:19 +00:00
|
|
|
x509->signer = x509;
|
|
|
|
pr_debug("- self-signed\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Look through the X.509 certificates in the PKCS#7 message's
|
|
|
|
* list to see if the next one is there.
|
|
|
|
*/
|
2016-04-06 15:13:33 +00:00
|
|
|
auth = sig->auth_ids[0];
|
2015-07-20 20:16:26 +00:00
|
|
|
if (auth) {
|
|
|
|
pr_debug("- want %*phN\n", auth->len, auth->data);
|
|
|
|
for (p = pkcs7->certs; p; p = p->next) {
|
|
|
|
pr_debug("- cmp [%u] %*phN\n",
|
|
|
|
p->index, p->id->len, p->id->data);
|
|
|
|
if (asymmetric_key_id_same(p->id, auth))
|
|
|
|
goto found_issuer_check_skid;
|
|
|
|
}
|
2016-07-17 23:10:39 +00:00
|
|
|
} else if (sig->auth_ids[1]) {
|
2016-04-06 15:13:33 +00:00
|
|
|
auth = sig->auth_ids[1];
|
2015-07-20 20:16:26 +00:00
|
|
|
pr_debug("- want %*phN\n", auth->len, auth->data);
|
|
|
|
for (p = pkcs7->certs; p; p = p->next) {
|
|
|
|
if (!p->skid)
|
|
|
|
continue;
|
|
|
|
pr_debug("- cmp [%u] %*phN\n",
|
|
|
|
p->index, p->skid->len, p->skid->data);
|
|
|
|
if (asymmetric_key_id_same(p->skid, auth))
|
|
|
|
goto found_issuer;
|
|
|
|
}
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* We didn't find the root of this chain */
|
|
|
|
pr_debug("- top\n");
|
|
|
|
return 0;
|
|
|
|
|
2015-07-20 20:16:26 +00:00
|
|
|
found_issuer_check_skid:
|
|
|
|
/* We matched issuer + serialNumber, but if there's an
|
|
|
|
* authKeyId.keyId, that must match the CA subjKeyId also.
|
|
|
|
*/
|
2016-04-06 15:13:33 +00:00
|
|
|
if (sig->auth_ids[1] &&
|
|
|
|
!asymmetric_key_id_same(p->skid, sig->auth_ids[1])) {
|
2015-07-20 20:16:26 +00:00
|
|
|
pr_warn("Sig %u: X.509 chain contains auth-skid nonmatch (%u->%u)\n",
|
|
|
|
sinfo->index, x509->index, p->index);
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
2014-07-01 15:40:19 +00:00
|
|
|
found_issuer:
|
2014-09-16 16:36:13 +00:00
|
|
|
pr_debug("- subject %s\n", p->subject);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (p->seen) {
|
|
|
|
pr_warn("Sig %u: X.509 chain contains loop\n",
|
|
|
|
sinfo->index);
|
|
|
|
return 0;
|
|
|
|
}
|
PKCS#7: fix certificate chain verification
When pkcs7_verify_sig_chain() is building the certificate chain for a
SignerInfo using the certificates in the PKCS#7 message, it is passing
the wrong arguments to public_key_verify_signature(). Consequently,
when the next certificate is supposed to be used to verify the previous
certificate, the next certificate is actually used to verify itself.
An attacker can use this bug to create a bogus certificate chain that
has no cryptographic relationship between the beginning and end.
Fortunately I couldn't quite find a way to use this to bypass the
overall signature verification, though it comes very close. Here's the
reasoning: due to the bug, every certificate in the chain beyond the
first actually has to be self-signed (where "self-signed" here refers to
the actual key and signature; an attacker might still manipulate the
certificate fields such that the self_signed flag doesn't actually get
set, and thus the chain doesn't end immediately). But to pass trust
validation (pkcs7_validate_trust()), either the SignerInfo or one of the
certificates has to actually be signed by a trusted key. Since only
self-signed certificates can be added to the chain, the only way for an
attacker to introduce a trusted signature is to include a self-signed
trusted certificate.
But, when pkcs7_validate_trust_one() reaches that certificate, instead
of trying to verify the signature on that certificate, it will actually
look up the corresponding trusted key, which will succeed, and then try
to verify the *previous* certificate, which will fail. Thus, disaster
is narrowly averted (as far as I could tell).
Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
2018-02-22 14:38:33 +00:00
|
|
|
ret = public_key_verify_signature(p->pub, x509->sig);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
x509->signer = p;
|
|
|
|
if (x509 == p) {
|
|
|
|
pr_debug("- self-signed\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
x509 = p;
|
|
|
|
might_sleep();
|
|
|
|
}
|
2014-09-16 16:36:15 +00:00
|
|
|
|
2022-01-19 00:54:35 +00:00
|
|
|
unsupported_sig_in_x509:
|
2014-09-16 16:36:15 +00:00
|
|
|
/* Just prune the certificate chain at this point if we lack some
|
|
|
|
* crypto module to go further. Note, however, we don't want to set
|
2016-04-06 15:13:34 +00:00
|
|
|
* sinfo->unsupported_crypto as the signed info block may still be
|
2014-09-16 16:36:15 +00:00
|
|
|
* validatable against an X.509 cert lower in the chain that we have a
|
|
|
|
* trusted copy of.
|
|
|
|
*/
|
2016-04-06 15:13:34 +00:00
|
|
|
return 0;
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
/*
|
|
|
|
* Verify one signed information block from a PKCS#7 message.
|
|
|
|
*/
|
|
|
|
static int pkcs7_verify_one(struct pkcs7_message *pkcs7,
|
|
|
|
struct pkcs7_signed_info *sinfo)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
kenter(",%u", sinfo->index);
|
|
|
|
|
|
|
|
/* First of all, digest the data in the PKCS#7 message and the
|
|
|
|
* signed information block
|
|
|
|
*/
|
|
|
|
ret = pkcs7_digest(pkcs7, sinfo);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2014-09-16 16:36:17 +00:00
|
|
|
/* Find the key for the signature if there is one */
|
2014-07-01 15:40:19 +00:00
|
|
|
ret = pkcs7_find_key(pkcs7, sinfo);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2014-09-16 16:36:17 +00:00
|
|
|
if (!sinfo->signer)
|
|
|
|
return 0;
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
pr_devel("Using X.509[%u] for sig %u\n",
|
|
|
|
sinfo->signer->index, sinfo->index);
|
|
|
|
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
/* Check that the PKCS#7 signing time is valid according to the X.509
|
|
|
|
* certificate. We can't, however, check against the system clock
|
|
|
|
* since that may not have been set yet and may be wrong.
|
|
|
|
*/
|
|
|
|
if (test_bit(sinfo_has_signing_time, &sinfo->aa_set)) {
|
|
|
|
if (sinfo->signing_time < sinfo->signer->valid_from ||
|
|
|
|
sinfo->signing_time > sinfo->signer->valid_to) {
|
|
|
|
pr_warn("Message signed outside of X.509 validity window\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
/* Verify the PKCS#7 binary against the key */
|
2016-04-06 15:13:33 +00:00
|
|
|
ret = public_key_verify_signature(sinfo->signer->pub, sinfo->sig);
|
2014-07-01 15:40:19 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
pr_devel("Verified signature %u\n", sinfo->index);
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
/* Verify the internal certificate chain */
|
|
|
|
return pkcs7_verify_sig_chain(pkcs7, sinfo);
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pkcs7_verify - Verify a PKCS#7 message
|
|
|
|
* @pkcs7: The PKCS#7 message to be verified
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
* @usage: The use to which the key is being put
|
2014-09-16 16:36:15 +00:00
|
|
|
*
|
|
|
|
* Verify a PKCS#7 message is internally consistent - that is, the data digest
|
|
|
|
* matches the digest in the AuthAttrs and any signature in the message or one
|
|
|
|
* of the X.509 certificates it carries that matches another X.509 cert in the
|
|
|
|
* message can be verified.
|
|
|
|
*
|
|
|
|
* This does not look to match the contents of the PKCS#7 message against any
|
|
|
|
* external public keys.
|
|
|
|
*
|
|
|
|
* Returns, in order of descending priority:
|
|
|
|
*
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
* (*) -EKEYREJECTED if a key was selected that had a usage restriction at
|
|
|
|
* odds with the specified usage, or:
|
|
|
|
*
|
2014-09-16 16:36:15 +00:00
|
|
|
* (*) -EKEYREJECTED if a signature failed to match for which we found an
|
|
|
|
* appropriate X.509 certificate, or:
|
|
|
|
*
|
|
|
|
* (*) -EBADMSG if some part of the message was invalid, or:
|
|
|
|
*
|
2018-02-22 14:38:33 +00:00
|
|
|
* (*) 0 if a signature chain passed verification, or:
|
2014-09-16 16:36:15 +00:00
|
|
|
*
|
2017-04-03 15:07:25 +00:00
|
|
|
* (*) -EKEYREJECTED if a blacklisted key was encountered, or:
|
|
|
|
*
|
|
|
|
* (*) -ENOPKG if none of the signature chains are verifiable because suitable
|
|
|
|
* crypto modules couldn't be found.
|
2014-07-01 15:40:19 +00:00
|
|
|
*/
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
int pkcs7_verify(struct pkcs7_message *pkcs7,
|
|
|
|
enum key_being_used_for usage)
|
2014-07-01 15:40:19 +00:00
|
|
|
{
|
|
|
|
struct pkcs7_signed_info *sinfo;
|
2017-04-03 15:07:25 +00:00
|
|
|
int actual_ret = -ENOPKG;
|
2016-04-06 15:13:34 +00:00
|
|
|
int ret;
|
2014-07-01 15:40:19 +00:00
|
|
|
|
|
|
|
kenter("");
|
|
|
|
|
PKCS#7: Appropriately restrict authenticated attributes and content type
A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.
Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:
(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.
(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:
(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.
(b) messageDigest. This must match the crypto digest of the data.
(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.
(d) S/MIME capabilities. We don't check the contents.
(e) Authenticode SP Opus Info. We don't check the contents.
(f) Authenticode Statement Type. We don't check the contents.
The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.
The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).
The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.
(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:
(*) VERIFYING_MODULE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.
(*) VERIFYING_FIRMWARE_SIGNATURE
This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.
(*) VERIFYING_UNSPECIFIED_SIGNATURE
This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.
(*) VERIFYING_KEXEC_PE_SIGNATURE
This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).
(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE
These are invalid in this context but are included for later use
when limiting the use of X.509 certs.
(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:
echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 14:22:27 +00:00
|
|
|
switch (usage) {
|
|
|
|
case VERIFYING_MODULE_SIGNATURE:
|
|
|
|
if (pkcs7->data_type != OID_data) {
|
|
|
|
pr_warn("Invalid module sig (not pkcs7-data)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
if (pkcs7->have_authattrs) {
|
|
|
|
pr_warn("Invalid module sig (has authattrs)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case VERIFYING_FIRMWARE_SIGNATURE:
|
|
|
|
if (pkcs7->data_type != OID_data) {
|
|
|
|
pr_warn("Invalid firmware sig (not pkcs7-data)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
if (!pkcs7->have_authattrs) {
|
|
|
|
pr_warn("Invalid firmware sig (missing authattrs)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case VERIFYING_KEXEC_PE_SIGNATURE:
|
|
|
|
if (pkcs7->data_type != OID_msIndirectData) {
|
|
|
|
pr_warn("Invalid kexec sig (not Authenticode)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
/* Authattr presence checked in parser */
|
|
|
|
break;
|
|
|
|
case VERIFYING_UNSPECIFIED_SIGNATURE:
|
|
|
|
if (pkcs7->data_type != OID_data) {
|
|
|
|
pr_warn("Invalid unspecified sig (not pkcs7-data)\n");
|
|
|
|
return -EKEYREJECTED;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-07-01 15:40:19 +00:00
|
|
|
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
|
|
|
|
ret = pkcs7_verify_one(pkcs7, sinfo);
|
2018-02-22 14:38:33 +00:00
|
|
|
if (sinfo->blacklisted) {
|
|
|
|
if (actual_ret == -ENOPKG)
|
|
|
|
actual_ret = -EKEYREJECTED;
|
|
|
|
continue;
|
|
|
|
}
|
2014-07-01 15:40:19 +00:00
|
|
|
if (ret < 0) {
|
2014-09-16 16:36:15 +00:00
|
|
|
if (ret == -ENOPKG) {
|
|
|
|
sinfo->unsupported_crypto = true;
|
|
|
|
continue;
|
|
|
|
}
|
2014-07-01 15:40:19 +00:00
|
|
|
kleave(" = %d", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2017-04-03 15:07:25 +00:00
|
|
|
actual_ret = 0;
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
|
2017-04-03 15:07:25 +00:00
|
|
|
kleave(" = %d", actual_ret);
|
|
|
|
return actual_ret;
|
2014-07-01 15:40:19 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pkcs7_verify);
|
2015-07-20 20:16:26 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* pkcs7_supply_detached_data - Supply the data needed to verify a PKCS#7 message
|
|
|
|
* @pkcs7: The PKCS#7 message
|
|
|
|
* @data: The data to be verified
|
|
|
|
* @datalen: The amount of data
|
|
|
|
*
|
|
|
|
* Supply the detached data needed to verify a PKCS#7 message. Note that no
|
|
|
|
* attempt to retain/pin the data is made. That is left to the caller. The
|
|
|
|
* data will not be modified by pkcs7_verify() and will not be freed when the
|
|
|
|
* PKCS#7 message is freed.
|
|
|
|
*
|
|
|
|
* Returns -EINVAL if data is already supplied in the message, 0 otherwise.
|
|
|
|
*/
|
|
|
|
int pkcs7_supply_detached_data(struct pkcs7_message *pkcs7,
|
|
|
|
const void *data, size_t datalen)
|
|
|
|
{
|
|
|
|
if (pkcs7->data) {
|
|
|
|
pr_debug("Data already supplied\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
pkcs7->data = data;
|
|
|
|
pkcs7->data_len = datalen;
|
|
|
|
return 0;
|
|
|
|
}
|