[Mono-dev] Mono.Security: Error when loading a CRL in ASN1

Sebastien Pouliot sebastien.pouliot at gmail.com
Sat Oct 17 10:30:13 EDT 2009


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.

> 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.

> 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



More information about the Mono-devel-list mailing list