- 23 3月, 2016 1 次提交
-
-
由 Nicolai Stange 提交于
Despite what the DocBook comment to pkcs7_validate_trust() says, the *_trusted argument is never set to false. pkcs7_validate_trust() only positively sets *_trusted upon encountering a trusted PKCS#7 SignedInfo block. This is quite unfortunate since its callers, system_verify_data() for example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust. Indeed, UBSAN splats when attempting to load the uninitialized local variable 'trusted' from system_verify_data() in pkcs7_validate_trust(): UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14 load of value 82 is not a valid value for type '_Bool' [...] Call Trace: [<ffffffff818c4d35>] dump_stack+0xbc/0x117 [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169 [<ffffffff8194113b>] ubsan_epilogue+0xd/0x4e [<ffffffff819419fa>] __ubsan_handle_load_invalid_value+0x111/0x158 [<ffffffff819418e9>] ? val_to_string.constprop.12+0xcf/0xcf [<ffffffff818334a4>] ? x509_request_asymmetric_key+0x114/0x370 [<ffffffff814b83f0>] ? kfree+0x220/0x370 [<ffffffff818312c2>] ? public_key_verify_signature_2+0x32/0x50 [<ffffffff81835e04>] pkcs7_validate_trust+0x524/0x5f0 [<ffffffff813c391a>] system_verify_data+0xca/0x170 [<ffffffff813c3850>] ? top_trace_array+0x9b/0x9b [<ffffffff81510b29>] ? __vfs_read+0x279/0x3d0 [<ffffffff8129372f>] mod_verify_sig+0x1ff/0x290 [...] The implication is that pkcs7_validate_trust() effectively grants trust when it really shouldn't have. Fix this by explicitly setting *_trusted to false at the very beginning of pkcs7_validate_trust(). Cc: <stable@vger.kernel.org> Signed-off-by: NNicolai Stange <nicstange@gmail.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 10 2月, 2016 1 次提交
-
-
由 Tadeusz Struk 提交于
This patch converts the module verification code to the new akcipher API. Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Acked-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
- 09 2月, 2016 1 次提交
-
-
由 Herbert Xu 提交于
This needs to go through the security tree so I'm reverting the patches for now. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 06 2月, 2016 1 次提交
-
-
由 Tadeusz Struk 提交于
This patch converts the module verification code to the new akcipher API. Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 07 8月, 2015 2 次提交
-
-
由 David Howells 提交于
If an X.509 certificate has an AuthorityKeyIdentifier extension that provides an issuer and serialNumber, then make it so that these are used in preference to the keyIdentifier field also held therein for searching for the signing certificate. If both the issuer+serialNumber and the keyIdentifier are supplied, then the certificate is looked up by the former but the latter is checked as well. If the latter doesn't match the subjectKeyIdentifier of the parent certificate, EKEYREJECTED is returned. This makes it possible to chain X.509 certificates based on the issuer and serialNumber fields rather than on subjectKeyIdentifier. This is necessary as we are having to deal with keys that are represented by X.509 certificates that lack a subjectKeyIdentifier. Signed-off-by: NDavid Howells <dhowells@redhat.com> Tested-by: NVivek Goyal <vgoyal@redhat.com>
-
由 David Howells 提交于
Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier, as the second part can be used to match X.509 certificates by issuer and serialNumber. Signed-off-by: NDavid Howells <dhowells@redhat.com> Tested-by: NVivek Goyal <vgoyal@redhat.com>
-
- 06 10月, 2014 1 次提交
-
-
由 Dmitry Kasatkin 提交于
Bring back the functionality whereby an asymmetric key can be matched with a partial match on one of its IDs. Whilst we're at it, allow for the possibility of having an increased number of IDs. Reported-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: NDmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
- 17 9月, 2014 4 次提交
-
-
由 David Howells 提交于
The X.509 certificate list in a PKCS#7 message is optional. To save space, we can omit the inclusion of any X.509 certificates if we are sure that we can look the relevant public key up by the serial number and issuer given in a signed info block. This also supports use of a signed info block for which we can't find a matching X.509 cert in the certificate list, though it be populated. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NVivek Goyal <vgoyal@redhat.com>
-
由 David Howells 提交于
Provide better handling of unsupported crypto when verifying a PKCS#7 message. If we can't bridge the gap between a pair of X.509 certs or between a signed info block and an X.509 cert because it involves some crypto we don't support, that's not necessarily the end of the world as there may be other ways points at which we can intersect with a ring of trusted keys. Instead, only produce ENOPKG immediately if all the signed info blocks in a PKCS#7 message require unsupported crypto to bridge to the first X.509 cert. Otherwise, we defer the generation of ENOPKG until we get ENOKEY during trust validation. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NVivek Goyal <vgoyal@redhat.com>
-
由 David Howells 提交于
Make use of the new match string preparsing to overhaul key identification when searching for asymmetric keys. The following changes are made: (1) Use the previously created asymmetric_key_id struct to hold the following key IDs derived from the X.509 certificate or PKCS#7 message: id: serial number + issuer skid: subjKeyId + subject authority: authKeyId + issuer (2) Replace the hex fingerprint attached to key->type_data[1] with an asymmetric_key_ids struct containing the id and the skid (if present). (3) Make the asymmetric_type match data preparse select one of two searches: (a) An iterative search for the key ID given if prefixed with "id:". The prefix is expected to be followed by a hex string giving the ID to search for. The criterion key ID is checked against all key IDs recorded on the key. (b) A direct search if the key ID is not prefixed with "id:". This will look for an exact match on the key description. (4) Make x509_request_asymmetric_key() take a key ID. This is then converted into "id:<hex>" and passed into keyring_search() where match preparsing will turn it back into a binary ID. (5) X.509 certificate verification then takes the authority key ID and looks up a key that matches it to find the public key for the certificate signature. (6) PKCS#7 certificate verification then takes the id key ID and looks up a key that matches it to find the public key for the signed information block signature. Additional changes: (1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the cert to be rejected with -EBADMSG. (2) The 'fingerprint' ID is gone. This was primarily intended to convey PGP public key fingerprints. If PGP is supported in future, this should generate a key ID that carries the fingerprint. (3) Th ca_keyid= kernel command line option is now converted to a key ID and used to match the authority key ID. Possibly this should only match the actual authKeyId part and not the issuer as well. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NVivek Goyal <vgoyal@redhat.com>
-
由 David Howells 提交于
Add a missing static (found by checker). Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NVivek Goyal <vgoyal@redhat.com>
-
- 29 7月, 2014 1 次提交
-
-
由 David Howells 提交于
pkcs7_request_asymmetric_key() and x509_request_asymmetric_key() do the same thing, the latter being a copy of the former created by the IMA folks, so drop the PKCS#7 version as the X.509 location is more general. Whilst we're at it, rename the arguments of x509_request_asymmetric_key() to better reflect what the values being passed in are intended to match on an X.509 cert. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
- 08 7月, 2014 1 次提交
-
-
由 David Howells 提交于
Find the intersection between the X.509 certificate chain contained in a PKCS#7 message and a set of keys that we already know and trust. Signed-off-by: NDavid Howells <dhowells@redhat.com> Acked-by: NVivek Goyal <vgoyal@redhat.com> Reviewed-by: NKees Cook <keescook@chromium.org>
-