PEFILE: Relax the check on the length of the PKCS#7 cert
authorDavid Howells <dhowells@redhat.com>
Tue, 2 Sep 2014 12:52:28 +0000 (13:52 +0100)
committerJames Morris <james.l.morris@oracle.com>
Wed, 3 Sep 2014 00:30:24 +0000 (10:30 +1000)
commit0aa0409401046b3ec44d9f6d6d015edab885a579
tree53ecc1eb9b71406c0fc20a73cf84bb67843a0de4
parent27419604f51a97d497853f14142c1059d46eb597
PEFILE: Relax the check on the length of the PKCS#7 cert

Relax the check on the length of the PKCS#7 cert as it appears that the PE
file wrapper size gets rounded up to the nearest 8.

The debugging output looks like this:

PEFILE: ==> verify_pefile_signature()
PEFILE: ==> pefile_parse_binary()
PEFILE: checksum @ 110
PEFILE: header size = 200
PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
PEFILE: sig wrapper = { 968, 200, 2 }
PEFILE: Signature data not PKCS#7

The wrapper is the first 8 bytes of the hex dump inside [].  This indicates a
length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
payload.

The ASN.1 wrapper begins [ ... 30 82 09 56 ].  That indicates an object of size
0x956 - a four byte discrepency, presumably just padding for alignment
purposes.

So we just check that the ASN.1 container is no bigger than the payload and
reduce the recorded size appropriately.

Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
127 or 255 bytes.  It's just about conceivable if no X.509 certs are included
in the PKCS#7 message.

Reported-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
crypto/asymmetric_keys/verify_pefile.c