July 30, 2015

The OpenSSL project releases new versions of its software to squash 12 security vulnerabilities

openssl-logo(LiveHacking.Com) – The OpenSSL Project announced on March 16th that it would make a new release of its OpenSSL suite to fix a number security defects. As promised the project published three new versions today, OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. The highest severity defect fixed by these releases is classified as High.

Before looking at the defects which have been fixed, it is worth noting that the project has reclassified its advisory about the FREAK vulnerability from Low to High. It was previously classified as Low severity because it was originally thought that server RSA export ciphersuite support was rare: a client was only vulnerable to a MITM attack against a server which supports an RSA export ciphersuite. Recent studies have shown that RSA export ciphersuites support is far more common.

The new security advisory lists only one High severity fix, for CVE-2015-0291 – ClientHello sigalgs DoS.  If a client connects to an OpenSSL 1.0.2 server and renegotiates with an invalid signature algorithms extension a NULL pointer dereference will occur. This can be exploited in a DoS attack against the server. This issue affects OpenSSL version 1.0.2.

The rest of the bug fixes are rated as Moderate or Low:

  • Multiblock corrupted pointer (CVE-2015-0290) – Severity: Moderate – OpenSSL 1.0.2 introduced the “multiblock” performance improvement. This feature only applies on 64 bit x86 architecture platforms that support AES NI instructions. A defect in the implementation of “multiblock” can cause OpenSSL’s internal write buffer to become incorrectly set to NULL when using non-blocking IO. Typically, when the user application is using a socket BIO for writing, this will only result in a failed connection. However if some other BIO is used then it is likely that a segmentation fault will be triggered, thus enabling a potential DoS attack.
  • Segmentation fault in DTLSv1_listen (CVE-2015-0207) – Severity: Moderate – The DTLSv1_listen function is intended to be stateless and processes the initial ClientHello from many peers. It is common for user code to loop over the call to DTLSv1_listen until a valid ClientHello is received with an associated cookie. A defect in the implementation of DTLSv1_listen means that state is preserved in the SSL object from one invocation to the next that can lead to a segmentation fault. Errors processing the initial ClientHello can trigger this scenario. An example of such an error could be that a DTLS1.0 only client is attempting to connect to a DTLS1.2 only server.
  • Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) – Severity: Moderate – The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication.
  • Segmentation fault for invalid PSS parameters (CVE-2015-0208) – Severity: Moderate – The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and invalid parameters. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication.
  • ASN.1 structure reuse memory corruption (CVE-2015-0287) – Severity: Moderate – Reusing a structure in ASN.1 parsing may allow an attacker to cause memory corruption via an invalid write. Such reuse is and has been strongly discouraged and is believed to be rare.
  • PKCS7 NULL pointer dereferences (CVE-2015-0289) – Severity: Moderate – The PKCS#7 parsing code does not handle missing outer ContentInfo correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing.
  • Base64 decode (CVE-2015-0292) – Severity: Moderate – A vulnerability existed in previous versions of OpenSSL related to the processing of base64 encoded data. Any code path that reads base64 data from an untrusted source could be affected (such as the PEM processing routines). Maliciously crafted base 64 data could trigger a segmenation fault or memory corruption. This was addressed in previous versions of OpenSSL but has not been included in any security advisory until now.
  • DoS via reachable assert in SSLv2 servers (CVE-2015-0293) – Severity: Moderate – A malicious client can trigger an OPENSSL_assert (i.e., an abort) in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message.
  • Empty CKE with client auth and DHE (CVE-2015-1787) – Severity: Moderate – If client auth is used then a server can seg fault in the event of a DHE ciphersuite being selected and a zero length ClientKeyExchange message being sent by the client. This could be exploited in a DoS attack.
  • Handshake with unseeded PRNG (CVE-2015-0285) – Severity: Low – Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with an unseeded PRNG.
  • Use After Free following d2i_ECPrivatekey error (CVE-2015-0209) – Severity: Low – A malformed EC private key file consumed via the d2i_ECPrivateKey function could cause a use after free condition. This, in turn, could cause a double free in several private key parsing functions (such as d2i_PrivateKey or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption for applications that receive EC private keys from untrusted sources. This scenario is considered rare.
  • X509_to_X509_REQ NULL pointer deref (CVE-2015-0288) – Severity: Low – The function X509_to_X509_REQ will crash with a NULL pointer dereference if the certificate key is invalid. This function is rarely used in practice.

New versions of OpenSSL are available as listed below:

  • OpenSSL 1.0.2a is now available, including bug and security fixes.
  • OpenSSL 1.0.1m is now available, including bug and security fixes.
  • OpenSSL 1.0.0r is now available, including bug and security fixes.
  • OpenSSL 0.9.8zf is now available, including bug and security fixes.

FREAK vulnerability weakens secure Web sites

padlock-icon-on-computer-monitor-showing-safety-security-and-protected_300x225(LiveHacking.Com) – FREAK (or ‘Factoring attack on RSA-EXPORT Keys’) is a newly disclosed vulnerability that can force browsers into using weaker encryption keys. Once the connection is using weaker keys then the traffic can be cracked relatively quickly. This then exposes all the information that was being sent over the secure connection.

The vulnerability stems directly from an old U.S. government policy that made it illegal to export strong encryption and required that weaker “export-grade” products be shipped to customers in other countries. These export restrictions were lifted in the late 1990s, but the weaker encryption got built-in into widely used software, some of which made its way back into USA.

In the 1990s the USA only allowed companies to create technology with 512-bit encryption for use overseas. The law was designed to limit the trade in military technology. But 512-bit encryption has long been seen as “unacceptably weak” and most security experts thought that its use had ceased completely.

According to the Washington Post, it is possible to crack the export-grade encryption key in about seven hours, using computers on Amazon Web services. The site freakattack.com has a list of sites that are vulnerable to FREAK. The list “includes news organizations, retailers and financial services sites such as americanexpress.com.” According to Nadia Heninger, a University of Pennsylvania cryptographer, over 5 million sites are vulnerable to this attack vector.

FREAK has been assigned the Common Vulnerabilities and Exposures identifier CVE-2015-0204. According to the description, “The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k allows remote SSL servers to conduct RSA-to-EXPORT_RSA downgrade attacks and facilitate brute-force decryption by offering a weak ephemeral RSA key in a noncompliant role.”

According to a security advisory from OpenSSL, “an OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session.”

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k, OpenSSL 1.0.0 users should upgrade to 1.0.0p, and OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team the following day.

It also looks like Android’s web browser and Apple’s Safari browser are vulnerable. According to Matt Green, “A group of cryptographers at INRIA, Microsoft Research and IMDEA have discovered some serious vulnerabilities in OpenSSL clients (e.g., Android) and Apple TLS/SSL clients (e.g., Safari) that allow a ‘man in the middle attacker’ to downgrade connections from ‘strong’ RSA to ‘export-grade’ RSA.”

NSA denies it knew about Heartbleed, says it is in the national interest for it to disclose vulnerabilities

odniIt looks like the ramifications of the Heartbleed bug in OpenSSL will be felt for quite a while to come. While security analysts are asking if the NSA had prior knowledge of the bug, cyber criminals are at work stealing data from sites which haven’t patched their servers and changed their SSL certificates. The Canadian Revenue Agency has said that the Heartbleed bug was the reason why an attacker was able to steal 900 social insurance numbers, and British parenting website Mumsnet said that username and password data used to authenticate users during log in was accessed before the site was able to patch its servers.

As for the NSA, the Director of National Intelligence has issued a statement saying that the NSA was not aware of the Heartbleed vulnerability until it was made public. The statement went on to say that the Federal government relies on OpenSSL the same as everyone else to protect the privacy of users of government websites and other online services.

However, what is even more important is that the statement categorically says that had the NSA, or any other of the agencies and organizations which make up the U.S. intelligence community, found the bug they would have reported it to the OpenSSL project.

“If the Federal government, including the intelligence community, had discovered this vulnerability prior to last week, it would have been disclosed to the community responsible for OpenSSL,” said the statement issued by the ODNI Public Affairs Office. The statement also said that when Federal agencies discover a new vulnerability “it is in the national interest to responsibly disclose the vulnerability rather than to hold it for an investigative or intelligence purpose.”

The Office of the Director of National Intelligence also said that in response to the President’s Review Group on Intelligence and Communications Technologies report that it had reinvigorated an interagency process for deciding when to share vulnerabilities.  According to the report, “The US Government should take additional steps to promote security, by (1) fully supporting and not undermining efforts to create encryption standards; (2) making clear that it will not in any way subvert, undermine, weaken, or make vulnerable generally available commercial encryption; and (3) supporting efforts to encourage the greater use of  encryption technology for data in transit, at rest, in the cloud, and in storage.” Such a statement is important following the accusations that the NSA tried (and succeeded) in weakening certain encryption standards.

The report also says that, “US policy should generally move to ensure that Zero Days are quickly blocked, so that the underlying vulnerabilities are patched on US Government and other networks. In  rare instances, US policy may briefly authorize using a Zero Day for high priority intelligence collection, following senior, interagency review involving all appropriate departments.”

This “rare” use of zero-day vulnerabilities was reiterated by the ODIN statement. “Unless there is a clear national security or law enforcement need, this process is biased toward responsibly disclosing such vulnerabilities.”

Heartbleed bug exposes OpenSSL’s secrets, patches available

heartbleedA serious security bug has been found in the ubiquitous OpenSSL encryption library that allows data to be stolen in its unencrypted form. According to the heartbleed.com website, which was set up expressly to inform system admins about the potential dangers, the Heartbleed bug can be exploited from the Internet and it allows an attacker to read up to 64k of the server’s memory at one time. By reading the memory an attacker can gain access to “the secret keys used to identify the service providers and to encrypt the traffic” along with “the names and passwords of the users and the actual content.” It means that attackers can eavesdrop communications that should have been otherwise encrypted.

A patched version of OpenSSL has already been published. According to the release notes, “a missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory” on a connected client or server. The OpenSSL project publicly thanked Neel Mehta of Google Security for discovering this bug and Adam Langley with Bodo Moeller for preparing the fix. It is recommended that all OpenSSL 1.0.1 users should upgrade to OpenSSL 1.0.1g. Those unable to immediately upgrade should recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. OpenSSL 1.0.0 and OpenSSL 0.9.8 are not vulnerable.

Heartbleed isn’t a design flaw in the SSL/TLS protocol specification but rather a bug in OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520).

Because the bug can expose the keys used for encrypting the connection, attackers are able to decrypt any past and future traffic to the encrypted connection since the primary keys have been exposed. Unfortunately to remedy the problem, not only does the server require patching but all the compromised keys need to be revoked and new keys reissued. It also means that users who have used an encrypted service (say a web mail service, online shopping or cloud service) will need to change their passwords as potentially the connection used to log in was not secure.

One very worrying aspect of this bug is not only the widespread use of OpenSSL, but also that the first vulnerable version was published two years ago. If this bug has been previously found (but not disclosed) by cyber criminals or government run security agencies then the last two years worth of encrypted traffic should be deemed as exposed. Even if it wasn’t found but the traffic was recorded then there are probably lots of state level agencies working right now to siphon off keys from around the net before things are revoked and changed.

Many Android apps open to man-in-the-middle attacks due to weak SSL usage

After injecting a virus signature database via a MITM attack over broken SSL, the AntiVirus app recognized itself as a virus and recommended to delete the detected malware.

Security researchers from the Leibniz University of Hanover and the computer science department at the Philipps University of Marburg have tested 13,500 popular free Android apps and found that 8.0% of these apps contain SSL/TLS implementations that are vulnerable to  Man-in-the-Middle (MITM) attacks.

The researchers created a tool called MalloDroid which is designed to detect potential vulnerabilities against MITM attacks. The tool performs static code analysis to analyze the networking API calls and extract valid HTTP(S) URLs, check the validity of the SSL certificates of all the extracted HTTPS hosts; and  identify apps that contain non-default trust managers. Running the tool on the 13,500 samples showed that 1,074 of the apps exhibited some kind of potential vulnerability.

From this 1,074 app a further 100 apps were picked for manual audit to investigate different SSL problem  including the accepting of all SSL certificates regardless of their validity. This manual audit revealed that 41 of the apps were vulnerable to MITM attacks due to SSL misuse.

A particularly embarrassing case the researchers found that the Zoner AntiVirus app updated its virus signatures via a broken SSL connection. As the developers considered the connection to be secure and couldn’t be tampered with there is no built-in verification or validation of the signature files downloaded. This meant that the team was able to insert its own signatures files. In one test they added the signature for the anti-virus app itself. The app then proceeded to recognize itself as malware and recommended that itself be to deleted. The Zoner AntiVirus app has been downloaded more than 500,000 times!

By the end of their research the team had managed to capture credentials for American Express, Diners Club, Paypal, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, IBM Sametime, remote servers, bank accounts and email accounts.

The total cumulative number of installs of all the MITM vulnerable apps is between 39.5 and 185 million users, according to the download numbers from Google’s Play Store.

90% of all HTTPS Websites Insecure

(LiveHacking.Com) – SSL Pulse, a new project that monitors the quality of SSL sites across the Internet and reports on its findings, has discovered that 90% of all HTTPS websites are insecure. The project has tested the top 200,000 SSL web sites on the Internet and discovered that nearly 180,000 of them are insecure.

The project measures key features about an SSL configuration and ranks the website according to the SSL Server Rating Guide. According to the report 40% of the worlds top SSL sites use 128 bit (or less) ciphers for data transfer and a handful of sites have certificates with keys below 1024 bits.

The biggest weaknesses are insecure renegotiation and susceptibility to a BEAST attack. Over 8,500 sites support insecure renegotiation which since 2009 as been considered insecure. A successful exploitation of this vulnerability allows an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. The results is that the attacker can impersonate a valid client and steal confidential data.

The SSL Pulse survey reports that 75% of SSL websites are still open to BEAST attacks. A BEAST attack is based on a flaw in the SSL protocol. A successful exploitation of this issue will result in a disclosure of a victim’s session cookies, allowing the attacker to completely hijack the application session. It was resolved in TLS v1.1, but now six years later, most clients and servers do not support newer protocol versions. To protected against a BEAST attack servers need to be configured to use TLS v1.1 or to only use RC4 with TLS v1.0 or SSL v3.0.

“About 50% (99,903 sites) got an A, which is a good result. Unfortunately, many of these A-grade sites (still) support insecure renegotiation (8,522 sites, or 8.5% of the well-configured ones) or are vulnerable to the BEAST attack (72,357 sites, or 72.4% of the well-configured ones). This leaves us with only 19,024 sites (or 9.59% of all sites) that are genuinely secure at this level of analysis,” wrote Ivan Ristic, director of engineering at Qualys and creator of SSL Labs.

The project hopes that these startling numbers will raise awareness of these issues and help web site owners improve their SSL implementations.

New Security Updates For All Active Branches of PostgreSQL

(LiveHacking.Com) – New security updates for all active versions PostgreSQL, the object-relational database system, have been released by the PostgreSQL Global Development Group. The updates are available for versions 9.1.3, 9.0.7, 8.4.11 and 8.3.18.

The update fixes vulnerability in three areas:

  • Permissions on a function called by a trigger are not checked.
  • SSL certificate name checks are truncated to 32 characters, allowing connection spoofing under some circumstances.
  • Line breaks in object names can be exploited to execute code when loading a pg_dump file.

The first fix prevents users from defining triggers which execute functions for which the user does not have EXECUTE permission. The problem was that CREATE TRIGGER failed to make any permissions check on the trigger function to be called. If the trigger function was marked SECURITY DEFINER, privilege escalation becomes possible.

The SSL fix resolves a problem with SSL common name truncation, which could allow hijacking of an SSL connection under exceptional circumstances. Since the name extracted from an SSL certificate was incorrectly truncated to 32 characters it was theoretically possible to spoof the name on a false certificate.

The final security fix is to the pg_dump program. pg_dump copies object names into comments in a SQL script without sanitizing them by using an object name which includes a newline it is possible to add SQL commands to the dump script. When the dump script is reloaded, the command would be executed with the privileges of whoever is running the script.

Users of pg_dump, users of SSL certificates for validation or users of triggers using SECURITY DEFINER should upgrade their installations immediately.

This release also contains 45 fixes to version 9.1, and a smaller number of fixes to older versions, including:

  • Fix btree index corruption from insertions concurrent with vacuuming
  • Recover from errors occurring during WAL replay of DROP TABLESPACE
  • Fix transient zeroing of shared buffers during WAL replay
  • Fix postmaster to attempt restart after a hot-standby crash
  • Fix corner case in SSI transaction cleanup
  • Update per-column permissions, not only per-table permissions, when changing table owner
  • Fix handling of data-modifying WITH subplans in READ COMMITTED rechecking
  • Fix for “could not find plan for CTE” failures
  • Fix unsupported node type error caused by COLLATE in an INSERT expression
  • Avoid crashing when we have problems deleting table files post-commit
  • Fix recently-introduced memory leak in processing of inet/cidr
  • Fix GIN cost estimation to handle column IN (…) index conditions
  • Fix I/O-conversion-related memory leaks in plpgsql
  • Teach pg_upgrade to handle renaming of plpython’s shared library (affecting upgrades to 9.1)

More information about the updates, including a full list of fixes and changes, can be found in the 9.1.39.0.78.4.11 and 8.3.18 release notes.

PostgreSQL can be downloaded from:

Mozilla Sends Another Message to Certificate Authorities

(LiveHacking.Com) – Mozilla has sent an email to all certificate authorities in the Mozilla root program to reiterate that the issuance of subordinate CA certificates for the purposes of SSL man-in-the-middle interception or traffic management is unacceptable. Mozilla has asked the CAs to revoke any such certificates by April 27, 2012. After that date, if it is found that a subordinate CA is being used for MITM, Mozilla could remove the corresponding root certificate from the Mozilla root program. This would mean the applications like Mozilla FireFox wouldn’t accept the certificate when presented.

“We made it clear that this practice remains unacceptable even when the intended deployment of such a certificate is restricted to a closed network,” said Johnathan Nightingale, Senior Director of Firefox Engineering.

Mozilla also reinforced the the Certificate Authorities responsibilities reminding them that they are accountable for every certificate they sign, directly or through its subordinates.

This isn’t the first time Mozilla has asked CAs to be more responsible. In September 2011 Mozilla sent a message to all the certificate authorities (which participate in the Mozilla root certificate program) requesting that they complete an audit of their PKI systems. This call to review and confirm the integrity of their certificate systems came after Mozilla removed the DigiNotar root certificate in response to its failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates.

Is SSL Falling Apart? New Research Papers Find More Holes

(LiveHacking.Com) – Two new research papers (here and here) have been published which examine the low level details of SSL, specifically randomness aspects, and the results are surprising. According to the “Ron was wrong, Whit is right” paper,  two out of every one thousand RSA moduli that on the Internet today offer no security. While the Princeton’s Center for Information Technology Policy blog shows that 0.4% of all the public keys used for SSL web site security can be remotely compromised.

Two in one thousand is  0.2%, Princeton is talking 0.4%. These aren’t huge numbers… but a search on Google for how many sites have “https://” in the URL shows 19,640,000,000 sites. Some of these are sites about HTTPS and aren’t secure sites. If just one quarter of those are really using https, that is 4,910,000,000 sites. 0.4% of 1,964,000,000. That is a lot of SSL certificates. And a huge potential number of sites which can be hacked.

“Our conclusion is that the validity of the assumption is questionable and that generating keys in the real world for “multiple-secrets” cryptosystems such as RSA is signi cantly riskier than for “single-secret” ones such as ElGamal or (EC)DSA which are based on Die-Hellman,” wrote Arjen K. Lenstra et al.

SSL has been having a hard time recently and it is starting to look as if this system isn’t as robust as previously thought. Recent SSL stories include the BEAST, Diginotar and Verisign.

“Unfortunately, we’ve found vulnerable devices from nearly every major manufacturer and we suspect that more than 200,000 devices, representing 4.1% of the SSL keys in our dataset, were generated with poor entropy. Any weak keys found to be generated by a device suggests that the entire class of devices may be vulnerable upon further analysis,” wrote Nadia Heninger.

OpenSSL Fix Flaw in Recent Bug Fix

(LiveHacking.Com) – Earlier this month, the OpenSSL project released updates to two new versions (OpenSSL 1.0.0f and 0.9.8s) of the popular open source toolkit for SSL/TLS to fix a total of six security flaws. One of the vulnerabilities fixed (CVE-2011-4108) was in OpenSSL’s DTLS implementation which allowed an efficient plaintext recovery attack. However Antonio Martin from Cisco Systems, Inc found a flaw in the in the fix that can be exploited in a denial of service attack. Only DTLS applications using OpenSSL 1.0.0f and 0.9.8s are affected.

To remedy this the OpenSSL project have now released OpenSSL 1.0.0g and OpenSSL 0.9.8t.