crypt32: Re: exception handling, part 2

[Juan Lang]

--- Saulius Krasuckas <saulius2 at ar.fi.lt> wrote:
> Hmm.  I don't understand the code, but if I change (+) BYTE tooBig 
> definition, then exceptions are gone, but return codes still differs in 
> the output (|):
(snip)
> I thought if there may be some sense in tuning tooBig value, then could
> it be done?

You may be right.  I'll explain what some of these errors mean:

In ASN.1 encoding, the first byte is the tag, or type of the value that
follows.  0x02 is an integer.  The second byte, if the high bit is not
set, is the number of bytes of the value.  So for example,

0x02 0x01 0x01

is the integer value 1.

If the high bit of the length byte is set, then the value of the length
byte & 0x7f is the number of length bytes that follow.  So, in long form:

0x02 0x81 0x01 0x01

is also the integer value 1.  0x81 & 0x7f is 0x01, meaning one length byte
follows.  The length value is 0x01, meaning one integer byte follows.

So the tooBig test does the following:
0x02 0x84 0xff 0xff 0xff 0xff

This means it's an integer, with 4 length bytes, whose value are
0xffffffff.  That means 0xffffffff bytes of integer value should follow
(which obviously don't.)  In WinXP, there's apparently a sanity check on
this to say this is too big a value, without trying to read this many
bytes.  That's what the test is trying to show:  CRYPT_E_ASN1_LARGE is
returned for an "insane" value.

> + tooBig[] = { 0x00, 0x84, 0xff, 0xff, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 8009310b

This is CRYPT_E_ASN1_BADTAG, which is true because the first byte is not a
valid tag.

> + tooBig[] = { 0x02, 0x84, 0xf0, 0xff, 0xff, 0xfc };
> + tooBig[] = { 0x02, 0x84, 0xff, 0x0f, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093102

This is CRYPT_E_ASN1_EOD, "end of data."  That could be useful.

> + tooBig[] = { 0x02, 0x04, 0xff, 0xff, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 00000000

This is a valid integer, 0xfffffffc, and there's already a test case for
these.

> + tooBig[] = { 0x02, 0x80, 0xff, 0xff, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093103

This is CRYPT_E_ASN1_CORRUPT, the length (0 bytes) is invalid.

> + tooBig[] = { 0x02, 0x83, 0xff, 0xff, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got c0000005

That's interesting too.  0x00ffffff bytes are supposed to follow, but an
access violation is caught.  So the WinME version catches some exceptions,
but not all?

> + tooBig[] = { 0x02, 0x84, 0x0f, 0xff, 0xff, 0xfc };
> + tooBig[] = { 0x02, 0x84, 0xff, 0xff, 0xff, 0xfc };
> | encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093106

That's CRYPT_E_ASN1_MEMORY, meaning out of memory.  Weird, it must try to
allocate this much?

Anyway, the WinME implementation is kind of strange buggy.  Thanks for
playing with it.  I think accepting both CRYPT_E_ASN1_LARGE and
CRYPT_E_ASN1_EOD, along with a value that results in CRYPT_E_ASN1_EOD,
would be a useful fix.  Do you want to patch it?

--Juan

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com