[UNIX] KAME IKE Daemon Racoon Fails to Verify RSA Signatures

From: SecuriTeam (support_at_securiteam.com)
Date: 04/08/04

  • Next message: SecuriTeam: "[NT] Panda ActiveScan Remote Buffer Overflow and DoS" 
    To: list@securiteam.com
Date: 8 Apr 2004 09:05:49 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      KAME IKE Daemon Racoon Fails to Verify RSA Signatures
    ------------------------------------------------------------------------

    SUMMARY

    The KAME IKE Daemon racoon authenticates the peer in Phase 1 using
    preshared keys, RSA signatures or GSS-API. When RSA signatures are used,
    racoon validates the X.509 certificate send by the peer but not the RSA
    signature. If the peer sends a valid and trusted X.509 certificate during
    Phase 1 any private key can be used to generate the RSA signature. The
    authentication will still succeed.

    DETAILS

    Vulnerable:
     * ipsec-tools versions prior to 0.2.4 (including) and versions prior to
    0.3rc4 (including)
     * FreeBSD 4.9 using racoon-20030711

    CVE Information:
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0155>
    CAN-2004-0155

    Impact:
    Very High: Since racoon is an often used IKE daemon on the *BSD platform
    and on the native Linux kernel 2.6 IPsec stack. If the attacker has access
    to a valid and trusted X.509 certificate he can establish an IPsec
    connection to racoon or can start a man-in-the-middle attack.

    Exploit:
    No exploit code is needed. Racoon itself can be used to exploit this
    security bug. The important configuration line:
     certificate_type x509 certificate badprivatekey;

    If the certificate is valid and trusted by the attacked racoon the
    attacker can connect using any 'badprivatekey'.

    Technical description:
    In function eay_rsa_verify() in file crypto_openssl.c:
           [...]
           evp = d2i_PUBKEY(NULL, &bp, pubkey->l);
           if (evp == NULL)
                 return 0;
           [...]

    In this context the function d2i_PUBKEY always returns NULL. The function
    therefore exits with the returncode 0 (success). The actual verification
    of the signature does not take place.
     
    Solution:
    The attached patch fixed the problem on Linux using the ipsec-tools
    package.

    --- 0.3rc4/src/racoon/crypto_openssl.c 2004-03-25 15:52:57.000000000 +0100
    +++ head/src/racoon/crypto_openssl.c 2004-04-05 16:17:26.168379313 +0200
    @@ -669,7 +669,7 @@ eay_check_x509sign(source, sig, cert)
     {
      X509 *x509;
      u_char *bp;
    - vchar_t pubkey;
    + EVP_PKEY *evp;
     
      bp = cert->v;
     
    @@ -681,10 +681,13 @@ eay_check_x509sign(source, sig, cert)
       return -1;
      }
     
    - pubkey.v = x509->cert_info->key->public_key->data;
    - pubkey.l = x509->cert_info->key->public_key->length;
    -
    - return eay_rsa_verify(source, sig, &pubkey);
    + evp = X509_get_pubkey(x509);
    + if (! evp) {
    + plog(LLV_ERROR, LOCATION, NULL, "X509_get_pubkey: %s\n",
    eay_strerror());
    + return -1;
    + }
    +
    + return eay_rsa_verify(source, sig, evp);
     }
     
     /*
    @@ -885,24 +888,16 @@ eay_rsa_sign(src, privkey)
     }
     
     int
    -eay_rsa_verify(src, sig, pubkey)
    - vchar_t *src, *sig, *pubkey;
    -{
    +eay_rsa_verify(src, sig, evp)
    + vchar_t *src, *sig;
      EVP_PKEY *evp;
    - u_char *bp = pubkey->v;
    +{
      vchar_t *xbuf = NULL;
      int pad = RSA_PKCS1_PADDING;
      int len = 0;
      int error;
     
    - evp = d2i_PUBKEY(NULL, &bp, pubkey->l);
    - if (evp == NULL)
    -#ifndef EAYDEBUG
    - return 0;
    -#endif
    -
      len = RSA_size(evp->pkey.rsa);
    -
      xbuf = vmalloc(len);
      if (xbuf == NULL) {
     #ifndef EAYDEBUG
    --- 0.3rc4/src/racoon/crypto_openssl.h 2004-01-08 19:35:24.000000000 +0100
    +++ head/src/racoon/crypto_openssl.h 2004-04-05 16:10:32.097535403 +0200
    @@ -57,7 +57,7 @@ extern int eay_check_pkcs7sign __P((vcha
     
     /* RSA */
     extern vchar_t *eay_rsa_sign __P((vchar_t *, vchar_t *));
    -extern int eay_rsa_verify __P((vchar_t *, vchar_t *, vchar_t *));
    +extern int eay_rsa_verify __P((vchar_t *, vchar_t *, EVP_PKEY *));
     
     /* ASN.1 */
     extern vchar_t *eay_get_pkcs1privkey __P((char *));

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:ralf@spenneberg.net> Ralf
    Spenneberg.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NT] Panda ActiveScan Remote Buffer Overflow and DoS"