Symptom: X509_cmp_current_time() returns unpredictable results when
checking an ASN1_GENERALIZEDTIME variable, sometimes claiming that a
timestamp is in the future when it is really in the past.
Diagnosis: X509_cmp_time() does not initialize atm.flags. This didn't
matter until somebody changed X509_time_adj_ex() to check for
ASN1_STRING_FLAG_MSTRING; since that change, ASN1_TIME variables with
type V_ASN1_GENERALIZEDTIME will fall through into ASN1_TIME_adj() if
whatever garbage was in the uninitialized field has that flag set.
The value returned by ASN1_TIME_adj() violates assumptions made by
X509_cmp_time(), yielding bogus results.
Versions affected: Bug is present in
openssl-1.0.0-stable-SNAP-20091116.tar.gz and
openssl-SNAP-20091116.tar.gz.
It wasn't present in openssl-SNAP-20090310.tar.gz. I haven't checked
other version to figure out exactly when it was introduced, I assume
it'll be obvious in CVS.
Impact: I don't know whether any OpenSSL library code hits this bug.
I found the problem because I use this function to check the
thisUpdate values described in draft-ietf-sidr-rpki-manifests.
Fix: The patch to fix this is trivial: just initialize atm.flags. The
twisty maze of functions involved could probably use an overhaul, but
initializing the variable appears to restore the broken functionality.
--- openssl-1.0.0-stable-SNAP-20091116/crypto/x509/x509_vfy.c.~1~
2009-10-31 20:02:38.000000000 +0000
+++ openssl-1.0.0-stable-SNAP-20091116/crypto/x509/x509_vfy.c 2009-11-17
02:46:43.000000000 +0000
@@ -1727,10 +1727,11 @@
offset= -offset;
}
atm.type=ctm->type;
atm.length=sizeof(buff2);
atm.data=(unsigned char *)buff2;
+ atm.flags=0;
if (X509_time_adj(&atm,-offset*60, cmp_time) == NULL)
return 0;
if (ctm->type == V_ASN1_UTCTIME)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
