Message-ID: <CAH8yC8kn59Msys8+J6Bvm0Qd-WYv8hwK1o+NqFJzN-kTn2pxHg@mail.gmail.com>
Date: Fri, 6 Sep 2013 14:22:00 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Arnis <arnis@...ee>
Cc: Full Disclosure List <full-disclosure@...ts.grok.org.uk>
Subject: Re: possible backdoor in OpenSSL X509 verification

> Can someone take a look on this shady X.509 certificate verification code
> (fails open in case of out-of-memory error):
>
> http://rt.openssl.org/Ticket/Display.html?id=2924
Well, I know Dr. Henson, Steve Marquess, Andy Poyakov, Tim Hudson, and
few others (to varying degrees). I can tell you its not an intentional
back door along the lines of http://cryptome.org/2012/01/0032.htm.

OpenSSL has one full time developer dedicated to maintaining the
library. Often times, he's busy consulting for the Foundation so he
does not have the opportunities to maintain the code like folks want.

> http://rt.openssl.org/Ticket/Display.html?id=2924
Keep in mind that OpenSSL recently migrated bug trackers (from an old
RT to a new RT), so that bug may be older than November, 2012.

And it might be fixed in the sources, too. The best I can tell, no one
really maintains that list (when's the last time you saw something
acknowledged?). Its more like a scratch pad.

> Noone from OpenSSL team has commented whether this is exploitable or
> should it be rewritten in safer manner.
OpenSSL is a open project, and it lack a solid engineering process.
What you are seeing is the effects of an ad hoc process, donated
developer time, and open source development.

> This is because "for" loop later does not require to find even a single
> issuer certificate from trust store and will happily break loop if last
> certificate is actually self signed."
Its just another bug that slipped through the cracks. No one is trying
to hide a back door.

I've tried to get the Foundation to address these problems with policy
("everything must have positive and negative test cases"). No one
really cared. Then I tried to get them to address it by accepting my
negative test cases (which broke things in practice). No one really
cared. Until the project improves their engineering process, things
won't change.

If you can put together a test case showing any certificate is
accepted (and subject to tampering or MitM), then that's a security
defect. You should probably get a CVE for it so it can be tracked.

Jeff

On Fri, Sep 6, 2013 at 10:28 AM, Arnis <arnis@...ee> wrote:
> Can someone take a look on this shady X.509 certificate verification code
> (fails open in case of out-of-memory error):
>
> http://rt.openssl.org/Ticket/Display.html?id=2924
>
> "Certificate chain verification in crypto/x509/x509_vfy.c
> X509_verify_cert() fails badly and may allow verification bypass if
> check_issued() on line 259 returns false negative on check whether the last
> certificate in chain is self signed. For example, check_issued() may
> return false negative in case of memory allocation failure (although could
> not find how to force that).
>
> 253 /* Examine last certificate in chain and see if it
> 254 * is self signed.
> 255 */
> 256
> 257 i=sk_X509_num(ctx->chain);
> 258 x=sk_X509_value(ctx->chain,i-1);
> 259 if (ctx->check_issued(ctx, x, x))
>
> This is because "for" loop later does not require to find even a single
> issuer certificate from trust store and will happily break loop if last
> certificate is actually self signed."
>
>
> Noone from OpenSSL team has commented whether this is exploitable or
> should it be rewritten in safer manner.
>
> P.S. Subject field inspired by latest NSA stories ;)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists