[Mono-dev] Mono.Security: Error when loading a CRL in ASN1
Jonathon Rossi
jono at jonorossi.com
Sat Oct 17 11:58:55 EDT 2009
I just generated a new crl using openssl 0.9.8k and it still has the same
issue of it overrunning the file length.
I'll send you one of the CRLs.
Thanks for your help.
On Sun, Oct 18, 2009 at 1:05 AM, Jonathon Rossi <jono at jonorossi.com> wrote:
> On Sun, Oct 18, 2009 at 12:30 AM, Sebastien Pouliot <
> sebastien.pouliot at gmail.com> wrote:
>
>> On Sun, 2009-10-18 at 00:06 +1000, Jonathon Rossi wrote:
>> > Thanks for your prompt response Sebastien.
>> >
>> > I tried option B first, and things seemed to turn out worse than
>> > before. You can see from the stack trace below that the length is now
>> > 121, rather than 104; and it is deeper in the recursion.
>> >
>> > Mono.Security.dll!Mono.Security.ASN1.DecodeTLV(byte[] asn1 =
>> > {byte[69238]}, ref int pos = 69138, out byte tag = 43, out int length
>> > = 121, out byte[] content = {byte[121]}) Line 279 + 0x33 bytes
>> > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 =
>> > {byte[69238]}, ref int anPos = 69138, int anLength = 69201) Line 249 +
>> > 0x36 bytes
>> > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 =
>> > {byte[69238]}, ref int anPos = 69136, int anLength = 69238) Line 258 +
>> > 0x2b bytes
>> > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 =
>> > {byte[69238]}, ref int anPos = 69134, int anLength = 69238) Line 258 +
>> > 0x2b bytes
>> > Mono.Security.dll!Mono.Security.ASN1.ASN1(byte[] data = {byte[69238]})
>> > Line 90 + 0x26 bytes
>> > Mono.Security.dll!Mono.Security.X509.X509Crl.Parse(byte[] crl =
>> > {byte[69238]}) Line 139 + 0x33 bytes
>> > Mono.Security.dll!Mono.Security.X509.X509Crl.X509Crl(byte[] crl =
>> > {byte[69238]}) Line 131 + 0x13 bytes
>> >
>> > I couldn't find the freeware asn1view tool you mention, but I tried
>> > some other ones I found in a google search. I can't build gasn1view on
>> > this machine so I couldn't try that one.
>> >
>> > ASN.1 Editor (http://lipingshare.com/Asn1Editor/) took 5mins to open
>> > the CRL and from what it shows the data ends at position 51088, which
>> > means there would be 18149 bytes of junk at the end? I cannot confirm
>> > whether it shows all revoked certificates in the sequence.
>>
>> Without confirmation about the entries or the CRL itself then no one can
>> say what are the last 18149 bytes. It could be extra junk or there could
>> be something corrupted.
>>
>
> I can send you a personal email with the CRL. Do you have time to look at
> this for me to determine if this is a mono bug or a corrupted crl?
>
>
>> > ASN1VE (http://www.obj-sys.com/products_asn1ve.php) threw up an error
>> > trying to open it.
>>
>> I can't be sure but I'll bet on a bad/damaged file. Did you said it was
>> working* somewhere ? (windows?) It could still be (somewhat) valid, e.g.
>> the important data is signed against tempering, but it's unlikely it
>> will work across systems.
>>
>
> I assume the CRL is working correctly on our Windows systems, it is at
> least not rejected by Windows. I'll have to test that.
>
> I just ran openssl asn1parse and it returned the same type of output that
> ASN1 Editor returned where there is empty data at the end. However, I just
> checked the version of openssl we have in our ca directory, and it is 0.9.6g
> (09/08/2002) so I think we should be upgrading.
>
> Thanks
>
>
>> > On Fri, Oct 16, 2009 at 10:09 PM, Sebastien Pouliot
>> > <sebastien.pouliot at gmail.com> wrote:
>> > On Fri, 2009-10-16 at 11:40 +1000, Jonathon Rossi wrote:
>> > > Hi,
>> > >
>> > > I am trying to load a CRL with the Mono.Security library
>> > (tried with
>> > > the 2.4.2.3 Windows binaries, and with the trunk) like this:
>> > > X509Crl crl = X509Crl.CreateFromFile(@"C:\ca.crl");
>> > >
>> > > And I get a CryptographicException: Input data cannot be
>> > coded as a
>> > > valid CRL.
>> > >
>> > > I have looking into the source code and this is occurring
>> > inside
>> > > ASN1.DecodeTLV. At this point the code is trying to do a
>> > block copy of
>> > > 104 bytes, where the asn1 array only has 103 left (pos
>> > +length), and it
>> > > throws an ArgumentException: "Offset and length were out of
>> > bounds for
>> > > the array or count is greater than the number of elements
>> > from index
>> > > to the end of the source collection."
>> > >
>> > > Mono.Security.dll!Mono.Security.ASN1.DecodeTLV(byte[] asn1 =
>> > > {byte[69237]}, ref int pos = 69134, out byte tag = 104, out
>> > int length
>> > > = 104, out byte[] content = {byte[104]}) Line 279 + 0x33
>> > bytes
>> >
>> >
>> > It looks weird (but not impossible) that both the tag and
>> > length are
>> > 104. However the problem is that that's only 103 byte left in
>> > the buffer
>> > - which (if the length is valid) is not legal ASN.1 (but not
>> > unheard of
>> > either, e.g. extra bytes are common and accepted by most
>> > parsers)
>> >
>> > > Mono.Security.dll!Mono.Security.ASN1.Decode(byte[] asn1 =
>> > > {byte[69237]}, ref int anPos = 69134, int anLength = 69237)
>> > Line 249 +
>> > > 0x36 bytes
>> > > Mono.Security.dll!Mono.Security.ASN1.ASN1(byte[] data =
>> > {byte[69237]})
>> > > Line 90 + 0x26 bytes
>> > > Mono.Security.dll!Mono.Security.X509.X509Crl.Parse(byte[]
>> > crl =
>> > > {byte[69237]}) Line 139 + 0x33 bytes
>> > > Mono.Security.dll!Mono.Security.X509.X509Crl.X509Crl(byte[]
>> > crl =
>> > > {byte[69237]}) Line 131 + 0x13 bytes
>> > > Mono.Security.dll!
>> > Mono.Security.X509.X509Crl.CreateFromFile(string
>> > > filename = "C:\\ca.crl") Line 421 + 0x20 bytes
>> > > ConsoleApplication2.exe!
>> > ConsoleApplication2.Program.Main(string[] args
>> > > = {string[0]}) Line 14 + 0x12 bytes
>> > >
>> > > The CRL is 68KB, and verifies using certutil.
>> >
>> >
>> > If the parser allows the truncation then the CRL can still
>> > verify if the
>> > missing part (the last byte in this case) is not part of the
>> > signed data
>> > of the CRL (e.g. its common to have unauthenticated attributes
>> > in ASN.1
>> > structures). This *could* be the case here (can't be sure
>> > without the
>> > actual data).
>> >
>> > > I cannot provide the CRL, however any pointers on what could
>> > be
>> > > causing this would be really helpful.
>> >
>> >
>> > You can:
>> >
>> > (a) try loading the CRL into asn1view (windows freeware) or
>> > gasnview
>> > (.net application in mono-tools, which requires gtk#) and look
>> > at what
>> > data exists at position 69134
>> >
>> > (b) load the CRL manually and copy it into a byte[] array that
>> > is one
>> > byte larger than the original one - that will validate the
>> > above theory.
>> > That's a lame workaround since it's specific to the current
>> > CRL you
>> > have.
>> >
>> > (c) open a bug report at bugzilla.novell.com and attach the
>> > CRL as a
>> > private attachment (only Novell employees will see it)
>> >
>> > (d) open a bug report at bugzilla.novell.com and attach the
>> > CRL and
>> > email me the CRL separately (only I will see it)
>> >
>> > Sebastien
>> >
>> >
>> >
>> >
>> > --
>> > Jono
>>
>>
>
>
> --
> Jono
>
--
Jono
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091018/1dd49764/attachment-0001.html
More information about the Mono-devel-list
mailing list