Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us

    GnuTLS is a secure communications library implementing the SSL, TLS, and DTLS protocols. It provides applications a way to use the above protocols without having to create their own cryptographic code. It is aimed to be portable and efficient with a focus on security and interoperability. In many cases, it is used instead of other libraries because GnuTLS is distributed under the GNU Lesser General Public License.

    However, it was found that the GnuTLS X.509 certificate verification code fails to properly handle certain error conditions that may occur during the certificate verification process. While verifying the certificate, GnuTLS would report it as successful verification of the certificate, even though verification should have resulted in a failure. This means that invalid certificates may be accepted as valid,

    What makes this flaw truly problematic is that GnuTLS is used in many applications and software packages, including Exim, Weechat, Mutt, Lynx, CUPS, and gnoMint. It could be used for web applications, e-mail programs, and other code that use the library. Therefore, it’s very difficult to ascertain the number of affected applications. Some of the few operating systems that support GnuTLS include:

    • Red Hat Enterprise Linux Desktop (v. 6)
    • Red Hat Enterprise Linux HPC Node (v. 6)
    • Red Hat Enterprise Linux Server (v. 6)
    • Red Hat Enterprise Linux Server AUS (v. 6.5)
    • Red Hat Enterprise Linux Server EUS (v. 6.5.z)
    • Red Hat Enterprise Linux Workstation (v. 6)
    • Ubuntu 12.10
    • Ubuntu 12.04 LTS
    • Ubuntu 10.04 LTS
    • openSUSE 11.4

    An attacker can use a specially crafted invalid security certificate and it will be accepted as valid by an application (e.g., browser, email client, feed reader, etc.) that uses GnuTLS. This can lead to disclosure of confidential information and may lead to complete control of victim’s system through a combination with another vulnerability.

    A Brief Look at the X.509 Code

    The X.509 protocols rely on a hierarchical trust model. Certification Authorities (CAs) are used to certify entities. Usually, more than one certification authorities exist, and certification authorities may certify other authorities to issue certificates as well. One needs to trust one or more CAs for secure communications. In that case, only the certificates issued by the trusted authorities are accepted.

    The root cause is a simple coding flaw that might have been present in several applications, including Linux OSs, for many years. More specifically, the bug involves GnuTLS’s library functions which are used for processing certificate verification of X.509 certificates.

    The main issue of the bug is the goto statement along with an uninitialized variable. goto is an infamous statement which has been criticized by many security researchers. In this instance, if the goto statement is being executed under certain error conditions, it can short-circuit the verification checks and bypass the certificate authentication process, allowing certificates to be presented as verified.

    In the verify.c function, check_if_ca returns “true” or rather 1, when the certificate is genuine or issued by the certified authority (CA). The return value should be zero if the certificate is not genuine or not issued by a certified authority. Few other functions return a negative value when they fail. In most programming languages, 0 evaluates to “false” and any other [integer] value to “true” . So the function is used by gnutls_x509_crt_verify, which verifies X509 certificates, passes the invalid certificate as genuine.

    In C, the programming error handling return codes are checked through the following:

    1. Return zero for success and non-zero (or less than zero mostly) for failure.
    2. Return code explicitly and check them later (for example, “yes”, “no,” etc.)
    3. Return 1 for success and 0 for failure.

    It appears that for GnuTLS , methods 1 and 3 are used together for return codes.

    For the bug fix, the “goto cleanup;” is replaced with “goto fail;”

    Label fail is defined as under
    Fail:
    result = 0;

    Before the bug fix, the cleanup label is defined as under cleanup:

    gnutls_datum_t cert_signed_data = { NULL, 0 };
    gnutls_datnum_t cert_signature = { NULL, 0 };
    gnutls_x509_crt_t issuer = NULL;
    int issuer_version, result;

    After the bug fix, the cleanup label has been changed as under cleanup:

    gnutls_datum_t cert_signed_data = { NULL, 0 };
    gnutls_datnum_t cert_signature = { NULL, 0 };
    gnutls_x509_crt_t issuer = NULL;
    int issuer_version, result=0;

    A comparison of of the fix can be viewed below:


    Figure 1. Screenshot of corrected return codes taken from Gitorious

    Methods of Attack

    An attacker could exploit this issue in many ways, depending on the usage of the vulnerable library. The bug may be exploited in man-in-the-middle attacks. If a victim tries to log in to a site, the attacker can present his own certificate, pretending to be that site. The fake certificate will pass the verification process and will be presented as an authentic certificate. It will thus appear as normal to the victim while the attacker will be able to intercept confidential data. Attacks like these are highly effective and often difficult to detect.

    An attacker could also host his own web server, with some web application having a fake certificate pretending to be any site of his choice. Through social engineering, he can then exploit this vulnerability.

    Mitigating Attacks 

    GnuTLS developers has issued an advisory regarding this issue. Any application using digital certificate verification libraries with other than latest patched version of GnuTLS are affected by this vulnerability. Users of GnuTLS are advised to upgrade to the following version to address the issue:

    • GnuTLS version (3.2.12 or 3.1.22)

    Users can also apply the patch for GnuTLS 2.12.x. All applications linked to the GnuTLS library must be restarted for the update to take effect.

     

    Hat tip to Nikos Mavrogiannopoulos of the Red Hat Security Technologies Team for spotting this flaw.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    Comments are closed.



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice