[MacPorts] #46596: openssl-1.0.1k breaks certificate signature verification

MacPorts noreply at macports.org
Sat Jan 17 12:23:10 PST 2015


#46596: openssl-1.0.1k breaks certificate signature verification
----------------------+--------------------------------
  Reporter:  uri@…    |      Owner:  macports-tickets@…
      Type:  defect   |     Status:  new
  Priority:  High     |  Milestone:
 Component:  ports    |    Version:  2.3.3
Resolution:           |   Keywords:  openssl
      Port:  openssl  |
----------------------+--------------------------------

Comment (by uri@…):

 Problem has been tracked to ASN.1 type comparison in
 "crypto/asn1/a_type.c". It is triggered from 1.0.1k version by the
 following patch:
 {{{
 diff --git a/crypto/x509/x_all.c b/crypto/x509/x_all.c
 index e06602d..fef55f8 100644 (file)
 --- a/crypto/x509/x_all.c
 +++ b/crypto/x509/x_all.c
 @@ -72,6 +72,8 @@

  int X509_verify(X509 *a, EVP_PKEY *r)
         {
 +       if (X509_ALGOR_cmp(a->sig_alg, a->cert_info->signature))
 +               return 0;
         return(ASN1_item_verify(ASN1_ITEM_rptr(X509_CINF),a->sig_alg,
                 a->signature,a->cert_info,r));
         }
 }}}
 The above patch invokes "X509_ALGOR_cmp" in "crypto/asn1/x_algor.c", which
 in turn invokes "ASN1_TYPE_cmp" in "crypto/asn1/a_type.c", where the
 comparison fails because one parameter is explicit ASN.1 NULL (0x05),
 while the other one is empty (not present, null-pointer). So ASN.1 NULL
 fails to compare to NULL, and the entire comparison fails with "not
 equal".

 I think the cause of this problem is somewhere in the certificate decoding
 piece, where either an explicit ASN.1 NULL gets added when it shouldn't,
 or the code forgets to add it when it should.

 The following is a reasonable secure workaround, until somebody figures
 why certificate parsing is screwed up:
 {{{
 $ diff -uw crypto/asn1/a_type.c.~1~ crypto/asn1/a_type.c
 --- crypto/asn1/a_type.c.~1~    2015-01-15 09:43:14.000000000 -0500
 +++ crypto/asn1/a_type.c        2015-01-17 15:12:17.000000000 -0500
 @@ -117,7 +117,22 @@
         {
         int result = -1;

 -       if (!a || !b || a->type != b->type) return -1;
 +       if (!a || !b) {
 +         if (!a && !b) /* both types are empty (null) */
 +           return 0;
 +         /* one is null, the other is maybe ASN.1 NULL (explicit) */
 +         if (a && !b) {
 +           if (a->type == V_ASN1_NULL)
 +             return 0;
 +         }
 +         if (b && !a) {
 +           if (b->type == V_ASN1_NULL)
 +             return 0;
 +         }
 +         return -1; /* the non-null (present) type isn't ASN.1 NULL */
 +       }
 +
 +       if (a->type != b->type) return -1;

         switch (a->type)
                 {

 }}}
 I've also attached it as a patch.

 For what it's worth - the same problem (and I suspect caused by the same
 misunderstanding leading to the same bug) is present in the latest beta
 (development) versions of Botan library, starting with 1.11.12.

-- 
Ticket URL: <https://trac.macports.org/ticket/46596#comment:2>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list