I have been having segfaults inside SSL when using the dovecot imap server, specifically within the imap-login process. It happens from within both 0.9.7a and 0.9.8e, but only with the Mac Mail client. The trace, when compiled with debug/efence, is:
#0 BN_bn2bin at bn_lib.c:651 651 *(to++)=(unsigned char)(l>>(8*(i% BN_BYTES)))&0xff; #1 RSA_eay_private_decrypt #2 RSA_private_decrypt #3 ssl3_get_client_key_exchange #4 ssl3_accept The relevant line inside RSA_eay_private_decrypt is: j=BN_bn2bin(ret,p); /* j is only used with no-padding mode */ The problem is that inside RSA_eay_private_decrypt BN_num_bytes(ret); has the value 254 whereas the buffer length: BN_num_bytes(rsa->n) has the value 128 (as does flen). I'm no expert on RSA but I assume that ret is read from the client and I suspect that Mail.app is sending invalid data. Should there not be a test for this condition and an intelligent response? If the buffer size is changed to the larger value will later routines be able to tell if the resulting data is valid? I obviously have the fear that other daemons are simply masking the problem in the classic buffer over-run way. I'm running 64-bit Scientific Linux 4.[34] (a RedHat Enterprise clone). I'm assuming that the fact that integers are 32 bits but pointers 64 is not the problem, despite the presence in bn_ctx.c of the statement: fprintf(stderr,"(%08x): ", (unsigned int)ctx); (!) Thanks for your help John ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
