Hi Moritz, hi security team, On Thu, Jan 08, 2009 at 10:30:14PM +0100, Moritz Muehlenhoff wrote: > CVE-2009-0049:
Yay. And 3.5.0 isn't even in source form anymore; I'm not even sure whether they actually are going to publish source for that. *sigh*. > Belgian eID middleware (eidlib) 2.6.0 and earlier does not properly check the > return value from the OpenSSL EVP_VerifyFinal function, which allows remote > attackers to bypass validation of the certificate chain via a malformed > SSL/TLS signature, a similar vulnerability to CVE-2008-5077. Since there appears to be no patch, AFAICS: wou...@country:~/debian/eID/belpic-2.6.0$ grep -r 'EVP_VerifyFinal' * src/newpkcs11/src/pkcs11/openssl.c: * finishing with EVP_VerifyFinal(). src/newpkcs11/src/pkcs11/openssl.c: res = EVP_VerifyFinal(md_ctx, signat, signat_len, pkey); src/newpkcs11/src/pkcs11/openssl.c: sc_debug(context, "EVP_VerifyFinal() returned %d\n", res); src/newpkcs11/src/tools/pkcs11-tool.c: err = EVP_VerifyFinal(&md_ctx, sig1, sigLen1, pkey); src/eidlib/Verify.cpp: iRet = 2*iDiffRNCert + !EVP_VerifyFinal(&cmd_ctx, (unsigned char *)pucSig, ulSigLen, pKey); The first two files are okay. In both cases, the return value is sent to a variable that is then properly checked using an if() {} else if() {} elseĀ {} block for the three possible return values of EVP_VerifyFinal(). The third appears to be somewhat more conspicious. Looking around in the code a bit, this is what it's *supposed* to return: /* Signature validation return codes */ #define BEID_SIGNATURE_NOT_VALIDATED -2 /* The signature is not valid ated */ #define BEID_SIGNATURE_PROCESSING_ERROR -1 /* Error verifying the signature. */ #define BEID_SIGNATURE_VALID 0 /* The signature is valid. */ #define BEID_SIGNATURE_INVALID 1 /* The signature is not valid. */ #define BEID_SIGNATURE_VALID_WRONG_RRNCERT 2 /* The signature is valid and wrong RRN certificate. */ #define BEID_SIGNATURE_INVALID_WRONG_RRNCERT 3 /* The signature is not valid and wrong RRN certificate. */ (that's from eiddefines.h) So the patch should be something like: --- Verify.cpp.orig 2009-01-09 03:48:56.000000000 +0100 +++ Verify.cpp 2009-01-09 03:42:44.000000000 +0100 @@ -1013,6 +1013,7 @@ unsigned char *pucRNCert = NULL; unsigned long ulRNCertLen = 0; BEID_Certif_Check tCertifs = {0}; + int evp_ret; if(m_pCertifManager == NULL) { @@ -1084,7 +1085,11 @@ EVP_VerifyInit(&cmd_ctx, EVP_sha1()); EVP_VerifyUpdate(&cmd_ctx, pucData, ulDataLen); - iRet = 2*iDiffRNCert + !EVP_VerifyFinal(&cmd_ctx, (unsigned char *)pucSig, ulSigLen, pKey); + evp_ret = EVP_VerifyFinal(&cmd_ctx, (unsigned char *)pucSig, ulSigLen, pKey); + if(evp_ret >= 0) { + evp_ret = 1 - evp_ret; + } + iRet = 2*iDiffRNCert + evp_ret; EVP_PKEY_free(pKey); X509_free(pX509); return iRet; Given that this is me guessing what the issue really is based on a description and some documentation that I'm not 100% sure I correctly parsed, I'd appreciate it if someone could verify and peer-review this before I upload it to unstable. Thanks, -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org