The m2crypto package (allowing to call OpenSSL functions from python scripts) incorrectly checked the result after calling various cryptographic decryption functions, allowing a malformed signature to be treated as a good signature rather than as an error. This issue affected the signature checks on DSA keys and ECDSA keys used with SSL/TLS. There are also calls to DSA_verify(), ECDSA_verify(), DSA_do_verify() and ECDSA_do_verify() that seem to think that -1 means error, and then return the return code. But 0 is also an error case (see man DSA_do_verify for example). Relevant part of the code: (SWIG/_dsa.i): 261 ret = DSA_do_verify(vbuf, vlen, sig, dsa); 262 DSA_SIG_free(sig); 263 if (ret == -1) 264 PyErr_SetString(_dsa_err, ERR_reason_error_string(ERR_get_error())); 265 return ret; SWIG/_ec.i 248 ret = ECDSA_do_verify(vbuf, vlen, sig, key); 249 ECDSA_SIG_free(sig); 250 if (ret == -1) 251 PyErr_SetString(_ec_err, ERR_reason_error_string(ERR_get_error())); 252 return ret; Occurences of other above mentioned functions: SWIG]# grep -r DSA_verify * | more _dsa.i: if ((ret = DSA_verify(0, vbuf, vlen, sbuf, slen, dsa)) == -1) _ec.i: if ((ret = ECDSA_verify(0, vbuf, vlen, sbuf, slen, key)) == -1) SWIG]# grep -r ECDSA_verify * | more _ec.i: if ((ret = ECDSA_verify(0, vbuf, vlen, sbuf, slen, key)) == -1) SWIG]# grep -r ECDSA_do_verify * | more _ec.i: ret = ECDSA_do_verify(vbuf, vlen, sig, key); Please check also the following two issues: The implementation of the verify_final() function in SWIG/_evp.i calls OpenSSL's EVP_VerifyFinal function (which was vulnerable to the recent OpenSSL's CVE-2008-5077 flaw) and 'only' returns its value. M2Crypto/EVP.py seems to document that as only returning 0 for failure but it can also return -1 on failure. All these issues are related with recent OpenSSL's CVE-2008-5077 flaw. Please see: https://bugzilla.redhat.com/show_bug.cgi?id=476671 for more information. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511515
The interface of these functions is: * return 1 if the signature is correct * return 0 if the signature is incorrect * raise an exception "on failure" (when OpenSSL returns -1) I'm not sure why OpenSSL separates "failure" and "error", but it doesn't really matter. AFAICS these functions are not used anywhere in m2crypto. Nor are thery used anywhere in Fedora (nothing in Fedora depends on m2crypto) or in RHEL (python-urlgrabber depends on M2Crypto, but it doesn't use any of the signature verification functions). If they are not used, they are never used incorrectly. The only thing that is incorrect is EVP.py:PKey.verify_final - either the comment is correct and the function should raise an exception on -1, or the comment is missing a description of the -1 return value. I'll submit a patch upstream to document the -1 return value. (Please reopen the bug report if I have missed something.)
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0127 to the following vulnerability: ** DISPUTED ** M2Crypto does not properly check the return value from the OpenSSL EVP_VerifyFinal, DSA_verify, ECDSA_verify, DSA_do_verify, and ECDSA_do_verify functions, which might allow remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a similar vulnerability to CVE-2008-5077. NOTE: a Linux vendor disputes the relevance of this report to the M2Crypto product because "these functions are not used anywhere in m2crypto." References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0127 http://openwall.com/lists/oss-security/2009/01/12/4 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511515
Perhaps a better description of my objection is the following: "There is no vulnerability in M2Crypto. Nowhere in the functions are the return values of OpenSSL functions interpreted incorrectly. The functions provide an interface to their users that may be considered confusing, but is not incorrect, nor it is a vulnerability. We have searched for uses of these functions in $our distribution to identify potential incorrect uses of the interface, and to the best of our knowledge these functions are never used in $our_distribution."