OpenSSL patches two high-severity flaws

Versions 1.0.2h and 1.0.1t of the cryptographic library also patch several more bugs of lesser impact

OpenSSL patches two high-severity flaws

OpenSSL has released versions 1.0.2h and 1.0.1t of its open source cryptographic library, fixing multiple security vulnerabilities that can lead to traffic being decrypted, denial-of-service attacks, and arbitrary code execution. One of the high-severity vulnerabilities is actually a hybrid of two low-risk bugs and can cause OpenSSL to crash.

Two seemingly unrelated bugs can be chained together to create a serious security problem. The first bug in CVE-2016-2108 is an issue with the ASN.1 parser that triggers a buffer underflow and performs an out-of-bounds write if zero is represented as a negative value. While the flaw was quietly patched last year, it wasn't considered a security vulnerability because an attacker would not be able to get the parser to create the value. However, there was an unrelated bug where the ASN.1 parser could misinterpret a large universal tag as a negative zero value.

Google's David Benjamin found that combining the two could cause an application to crash or let an attacker remotely execute malicious code. In this scenario, an application deserializes untrusted ASN.1 structures containing an ANY field and reserializes the structures later to trigger an out-of-bounds write. "This has been shown to cause memory corruption that is potentially exploitable with some malloc implementations," the OpenSSL team wrote.

The advisory warned that applications that parse and re-encode X509 certificates are vulnerable. Applications that verify RSA signatures on X509 certificates may also be vulnerable, but only certificates with valid signatures can trigger the flaw. The attack method doesn't work if OpenSSL has been patched recently, since the first bug was patched in June 2015.

OpenSSL also fixed an oracle padding issue (CVE-2016-2107) where man-in-the-middle attackers could corrupt plaintext padding around encrypted messages and decrypt traffic.

Attackers would be able to steal credentials and other sensitive information transferred over HTTPS if the connection used an AES-CBC cipher and the server supported AES-NI. The high-severity flaw was inadvertently introduced in February 2013 as part of the patch for the Lucky 13 TLS attack.

OpenSSL 1.0.2h and 1.0.1t also fixed two low-severity issues related to how large amounts of input data for EVP_EncodeUpdate() (CVE-2016-2105) and EVP_EncryptUpdate() (CVE-2016-2106) functions can overflow a length check and trigger heap corruption. The functions are used for Base64 encoding of binary data and are mainly used within the OpenSSL command-line applications. The team analyzed all instances of where EVP_EncryptUpdate() and EVP_CipherUpdate() are called internally and said there are no instances in internal usage where an overflow could occur.

"This could still represent a security issue for end user code that calls this function directly," the advisory warned. User applications that call APIs directly with large amounts of untrusted data may be vulnerable.

CVE-2016-2109 is another low-severity flaw in the ASN.1 BIO that could be exploited to churn through memory at a high rate and potentially exhaust it and crash the target system. Applications parsing untrusted data through d2i BIO functions are affected, but memory-based functions such as d2i_X509() are not. TLS applications are not affected by the flaw.

CVE-2016-2176 is the final low-severity flaw, which can overload the X509_NAME_oneline() function in EBCDIC systems. Arbitrary stack data could be returned in the buffer.

Patching is always important, but especially so when it comes to applying OpenSSL security updates. The widely used protocol is the basis of Internet communications. Attackers are quick to adopt exploits targeting vulnerabilities to decrypt and intercept information being transferred online.

This story, "OpenSSL patches two high-severity flaws" was originally published by InfoWorld.

Copyright © 2016 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)