Patch for bug 34388
Juan Lang
juan.lang at gmail.com
Fri Sep 6 14:10:45 CDT 2013
Hiya Chip,
I don't have an answer off the top of my head. But let's see if we can
unpack that ASN.1 a bit.
First, with the type, notice that crypt32_private.h defines a few useful
types that Microsoft omitted for some reason from their public header,
including:
#define ASN_SETOF (ASN_UNIVERSAL | ASN_PRIMITIVE | 0x11)
Okay, so that's what we're dealing with.
Next, to help sort it out: write each of the blobs to a binary, and
interpret it with "openssl asn1parse -dump -i -inform DER". Here's the
output from PKCSSignerWithUnknownItem31:
0:d=0 hl=4 l= 146 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 25 cons: SEQUENCE
9:d=2 hl=2 l= 20 cons: SEQUENCE
11:d=3 hl=2 l= 18 cons: SET
13:d=4 hl=2 l= 16 cons: SEQUENCE
15:d=5 hl=2 l= 3 prim: OBJECT :commonName
20:d=5 hl=2 l= 9 prim: PRINTABLESTRING :Juan Lang
31:d=2 hl=2 l= 1 prim: INTEGER :01
34:d=1 hl=2 l= 6 cons: SEQUENCE
36:d=2 hl=2 l= 2 prim: OBJECT :1.2.3
40:d=2 hl=2 l= 0 prim: NULL
42:d=1 hl=2 l= 96 cons: SET
44:d=2 hl=2 l= 0 prim: EOC
(a bunch of these omitted)
140:d=1 hl=2 l= 6 cons: SEQUENCE
142:d=2 hl=2 l= 2 prim: OBJECT :1.5.6
146:d=2 hl=2 l= 0 prim: NULL
148:d=1 hl=2 l= 0 prim: OCTET STRING
And here's the output from PKCSSignerWithAuthAttrAndUnknownItem31:
0:d=0 hl=4 l= 196 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 25 cons: SEQUENCE
9:d=2 hl=2 l= 20 cons: SEQUENCE
11:d=3 hl=2 l= 18 cons: SET
13:d=4 hl=2 l= 16 cons: SEQUENCE
15:d=5 hl=2 l= 3 prim: OBJECT :commonName
20:d=5 hl=2 l= 9 prim: PRINTABLESTRING :Juan Lang
31:d=2 hl=2 l= 1 prim: INTEGER :01
34:d=1 hl=2 l= 6 cons: SEQUENCE
36:d=2 hl=2 l= 2 prim: OBJECT :1.2.3
40:d=2 hl=2 l= 0 prim: NULL
42:d=1 hl=2 l= 32 cons: cont [ 0 ]
44:d=2 hl=2 l= 30 cons: SEQUENCE
46:d=3 hl=2 l= 3 prim: OBJECT :commonName
51:d=3 hl=2 l= 23 cons: SET
53:d=4 hl=2 l= 21 cons: SEQUENCE
55:d=5 hl=2 l= 19 cons: SET
57:d=6 hl=2 l= 17 cons: SEQUENCE
59:d=7 hl=2 l= 3 prim: OBJECT :commonName
64:d=7 hl=2 l= 10 prim: PRINTABLESTRING :Juan Lang
76:d=1 hl=2 l= 96 cons: SET
78:d=2 hl=2 l= 0 prim: EOC
(again, a bunch of these omitted)
174:d=1 hl=2 l= 6 cons: SEQUENCE
176:d=2 hl=2 l= 2 prim: OBJECT :1.5.6
180:d=2 hl=2 l= 0 prim: NULL
182:d=1 hl=2 l= 16 prim: OCTET STRING
0000 - 00 01 02 03 04 05 06 07-08 09 0a 0b 0c 0d 0e 0f
................
You can see that in the latter case, you've got a context-specific tag of 0
wrapping a sequence containing a non-empty set. That context-specific [0]
looks an awful lot like "signedAttrs [0] IMPLICIT SignedAttributes
OPTIONAL," no? And SignedAttributes is defined as "SignedAttributes ::= SET
SIZE (1..MAX) OF Attribute".
Anyway, in the latter case, the signed attributes precede the set, and in
the former case they're missing.
In addition to that, it's not entirely clear from your test results that
it's expected to succeed in Windows in either case:
+ ret = pCryptDecodeObjectEx(dwEncoding, PKCS7_SIGNER_INFO,
+ PKCSSignerWithAuthAttrAndUnknownItem31,
+ sizeof(PKCSSignerWithAuthAttrAndUnknownItem31),
+ CRYPT_DECODE_ALLOC_FLAG, NULL, &buf, &size);
+ if (ret)
You don't have an ok(ret) here. I can't blame you too much for that,
though: it looks like I omitted a bunch of ok(ret)s in my tests too. Sigh.
Sorry about that. Could you add that and see what that turns up?
--Juan
On Thu, Sep 5, 2013 at 11:57 PM, Charles Davis <cdavis5x at gmail.com> wrote:
> Hi Juan,
>
> I need some advice.
>
> Attached is a patch to fix bug 34388, where an app that tries to verify
> its code signature fails because Wine, while parsing the certificates
> embedded within the signature, encounters an item in the CMS signer info
> (tag 0x31, i.e. ASN_UNIVERSAL | ASN_CONSTRUCTOR | 0x11), right before the
> HashEncryptionAlgorithm sequence item, that it doesn't yet know how to
> decode. This patch (which just skips the item in question) allows that app
> to successfully verify its code signature and run, but...
>
> My testing on Windows (cf. job 2037 on newtestbot) shows some interesting
> behavior. Windows will indeed accept this item, but only if the AuthAttrs
> item is also present and immediately precedes it in the sequence. (The
> other test bails out with CRYPT_E_ASN_BADTAG.) I don't quite know what to
> make of this. The odd thing is that the certificate in question doesn't
> have this optional AuthAttrs item, and yet (in most cases, at least) most
> people who run this particular app on Windows do not have this problem. I
> can't seem to find anything about this from reading the relevant RFCs. Is
> there something I'm missing?
>
> Thanks.
>
> Chip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20130906/4e1716cc/attachment.html>
More information about the wine-devel
mailing list