[Mono-dev] Mono.Security: Error when loading a CRL in ASN1
Jonathon Rossi
jono at jonorossi.com
Sat Oct 17 11:05:43 EDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091018/cc52192c/attachment.html
More information about the Mono-devel-list
mailing list