Hi

On 02.02.2013 23:55, Alexander Hollerith wrote:
The php openssl library implements a function named openssl_csr_sign() and 
inside that function one can find the following line:
        X509_gmtime_adj(X509_get_notAfter(new_cert), (long)60*60*24*num_days);

This obviously provokes an overflow in cases of large values of "num_days", say 36500 (representing 
100 years), on 32-bit systems where usually "sizeof(long) = 4". The bug report I opened in the php 
bugtracker was closed with "not a bug" pointing to the openssl API. The php people correctly 
pointed out that X509_gmtime_adj() needs a long value as parameter.

with OpenSSL on 32-bit systems you can't generate a certificate thats validity goes above 19 jan. 2038;
the linux time is only 64-bit on 64-bit systems;
I found that OpenSSL Cert creation example code 
(https://github.com/cloudmeter/openssl/blob/master/demos/x509/mkcert.c) has 
that very same line in it and should therefore be subject to the same issue:
        X509_set_version(x,2);
        ASN1_INTEGER_set(X509_get_serialNumber(x),serial);
        X509_gmtime_adj(X509_get_notBefore(x),0);
        X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days);
        X509_set_pubkey(x,pk);

After searching around a bit I assume that with newer versions of OpenSSL using 
OPENSSL_gmtime_adj() or X509_time_adj_ex instead of X509_gmtime_adj() would 
maybe resolve this obvious limitation.
its not an resolve by newer versions, its an resolve by 64-bit systems;
in C/C++ long can be 64-bit on 64-bit systems;
it cannot be assumed that generally datatype long is 32-bit;

as strange it sounds,
a newer OpenSSL version on a 32-bit Linux has these limitations (e.g. OpenSSL 1.0.0 on CentOS 6.3), but not an older OpenSSL version on a 64-bit Linux (e.g. OpenSSL.0.9.7 on CentOS 4.x);

so migrating to 64-bit will be a neccessary step.

Greetings
Walter

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to