OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test certificate and its CA cert that illustrate the problem are attached, as well as the patch/workaround).
Here’s how the problem manifests itself:
$ openssl version -f
compiler: -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3
-DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM
$ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US
error 7 at 0 depth lookup:certificate signature failure
$ /usr/bin/openssl version -f
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings
-fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
-DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB
-mmacosx-version-min=10.6
$ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem
RabbitMQ_Test.pem: OK
$
Probable cause: certificate decoder either fails to encode ASN.1 NULL for
"signature algorithm parameters” when it should, or encodes an explicit ASN.1
NULL when it shouldn’t. As a result, the comparison code ASN1_TYPE_cmp in
crypto/asn1/a_type.c is presented with a case when one argument is empty (a
null pointer), and the other one is of type ASN.1 NULL (0x5). In result, the
comparison fails when it actually should return OK (0).
Here’s the workaround that I consider secure. I think it should be used, at
least until the cause for the above decoding confusion is could and fixed.
Also, since I’m not an OpenSSL developer and thus am not a member of the
mailing list, I’d appreciate if you could copy replies to this email as well.
Thanks!
--- 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)
{
--
Uri Blumenthal
[email protected]
| OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test certificate and its CA cert that illustrate the problem are attached, as well as the patch/workaround). Here’s how the problem manifests itself: $ openssl version -f compiler: -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US error 7 at 0 depth lookup:certificate signature failure $ /usr/bin/openssl version -f compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6 $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem RabbitMQ_Test.pem: OK $ Probable cause: certificate decoder either fails to encode ASN.1 NULL for "signature algorithm parameters” when it should, or encodes an explicit ASN.1 NULL when it shouldn’t. As a result, the comparison code ASN1_TYPE_cmp in crypto/asn1/a_type.c is presented with a case when one argument is empty (a null pointer), and the other one is of type ASN.1 NULL (0x5). In result, the comparison fails when it actually should return OK (0). Here’s the workaround that I consider secure. I think it should be used, at least until the cause for the above decoding confusion is could and fixed. Also, since I’m not an OpenSSL developer and thus am not a member of the mailing list, I’d appreciate if you could copy replies to this email as well. Thanks! --- 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)
{ |
RabbitMQ_Test_CA.pem
Description: application/x509-ca-cert
RabbitMQ_Test.pem
Description: application/x509-ca-cert
openssl-1.0.1k.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
