diff options
author | David Howells <dhowells@redhat.com> | 2014-09-02 13:52:28 +0100 |
---|---|---|
committer | James Morris <james.l.morris@oracle.com> | 2014-09-03 10:30:24 +1000 |
commit | 0aa0409401046b3ec44d9f6d6d015edab885a579 (patch) | |
tree | 53ecc1eb9b71406c0fc20a73cf84bb67843a0de4 /crypto/arc4.c | |
parent | 27419604f51a97d497853f14142c1059d46eb597 (diff) | |
download | linux-0aa0409401046b3ec44d9f6d6d015edab885a579.tar.bz2 |
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>
Diffstat (limited to 'crypto/arc4.c')
0 files changed, 0 insertions, 0 deletions