PKCS#7: Appropriately restrict authenticated attributes and content type
authorDavid Howells <dhowells@redhat.com>
Wed, 5 Aug 2015 14:22:27 +0000 (15:22 +0100)
committerDavid Howells <dhowells@redhat.com>
Wed, 12 Aug 2015 16:01:01 +0000 (17:01 +0100)
commit99db44350672c8a5ee9a7b0a6f4cd6ff10136065
tree4a135d2e049e6e9db195b96a56d03363774b1f7b
parentf29299b4801076e14bb149cb2fc44bd8dc2f51cc
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>
16 files changed:
arch/x86/kernel/kexec-bzimage64.c
crypto/asymmetric_keys/asymmetric_type.c
crypto/asymmetric_keys/pkcs7.asn1
crypto/asymmetric_keys/pkcs7_key_type.c
crypto/asymmetric_keys/pkcs7_parser.c
crypto/asymmetric_keys/pkcs7_parser.h
crypto/asymmetric_keys/pkcs7_verify.c
crypto/asymmetric_keys/verify_pefile.c
include/crypto/pkcs7.h
include/crypto/public_key.h
include/keys/system_keyring.h
include/linux/oid_registry.h
include/linux/verify_pefile.h
kernel/module_signing.c
kernel/system_keyring.c
scripts/sign-file.c