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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]