October 2, 2014

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.

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.

Six Security Flaws Fixed in OpenSSL

(LiveHacking.Com) – The OpenSSL project team has released two new versions of the popular open source toolkit for SSL/TLS. OpenSSL 1.0.0f and 0.9.8s fix a total of six security flaws. Of the six fixes, four apply to 1.0.0f and 0.9.8s together and then each version has one unique fix for its code stream.

The relevant security advisory lists the following:

  1. DTLS Plaintext Recovery Attack (CVE-2011-4108) - Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can befound at http://www.isg.rhul.ac.uk/~kp/dtls.pdf
  2. Double-free in Policy Checks (CVE-2011-4109) - If X509_V_FLAG_POLICY_CHECK is set in OpenSSL 0.9.8, then a policy check failure can lead to a double-free. The bug does not occur unless this flag is set. Users of OpenSSL 1.0.0 are not affected.
  3. Uninitialized SSL 3.0 Padding (CVE-2011-4576) - OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as block cipher padding in SSL 3.0 records. This affects both clients and servers that accept SSL 3.0 handshakes: those that call SSL_CTX_new with SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does not affect TLS. As a result, in each record, up to 15 bytes of uninitialized memory may be sent, encrypted, to the SSL peer. This could include sensitive contents of previously freed memory. However, in practice, most deployments do not use SSL_MODE_RELEASE_BUFFERS and therefore have a single write buffer per connection. That write buffer is partially filled with non-sensitive, handshake data at the beginning of the connection and, thereafter, only records which are longer any any previously sent record leak any non-encrypted data. This, combined with the small number of bytes leaked per record, serves to limit to severity of this issue.
  4. Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577) - RFC 3779 data can be included in certificates, and if it is malformed, may trigger an assertion failure. This could be used in a denial-of-service attack. Note, however, that in the standard release of OpenSSL, RFC 3779 support is disabled by default, and in this case OpenSSL is not vulnerable. Builds of OpenSSL are vulnerable if configured with “enable-rfc3779″.
  5. SGC Restart DoS Attack (CVE-2011-4619) - Support for handshake restarts for server gated cryptograpy (SGC) can be used in a denial-of-service attack.
  6. Invalid GOST parameters DoS Attack (CVE-2012-0027) - A malicious TLS client can send an invalid set of GOST parameters which will cause the server to crash due to lack of error checking. This could be used in a denial-of-service attack. Only users of the OpenSSL GOST ENGINE are affected by this bug.

OpenSSL 1.0.0f  is considered the current best version of OpenSSL available and it is recommended that users of older versions upgrade as soon as possible. OpenSSL 1.0.0f is available for download via HTTP and FTP from the following master locations:

For a complete list of changes, please seehttp://cvs.openssl.org/getfile?f=openssl/CHANGES&v=OpenSSL_1_0_0f.

 

OpenSSL Released a New Version and Fixed Two Vulnerabilities

OpenSSL has released version 1.0.0.c of OpenSSL SSL implementation. With reference to OpenSSL security advisory, the following security issues have been fixed in the new version:

OpenSSL Ciphersuite Downgrade Attack

A flaw has been found in the OpenSSL SSL/TLS server code where an old bug workaround allows malicous clients to modify the stored session cache ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one on subsequent connections.

  • The OpenSSL security team would like to thank Martin Rex for reporting this issue.
  • This vulnerability is tracked as CVE-2010-4180

OpenSSL JPAKE validation error

Sebastian Martini found an error in OpenSSL’s J-PAKE implementation which could lead to successful validation by someone with no knowledge of the shared secret. This error is fixed in 1.0.0c. Details of the problem can be found here: http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf

Note that the OpenSSL Team still consider our implementation of J-PAKE to be experimental and is not compiled by default.

  • This issue is tracked as CVE-2010-4252

More information is available here.

Source:[openssl.org]

Related Articles:

Red Hat: Vulnerability in OpenSSL

Red Hat released update packages for openssl that fix one security issue for Red Hat Enterprise Linux 6.The Red Hat Security Response Team has rated this update as having important security impact.

OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, as well as a full-strength, general purpose cryptography library.

[ad code=6 align=left]

With reference to Red Hat support forum, A race condition flaw has been found in the OpenSSL TLS server extension parsing code, which could affect some multithreaded OpenSSL applications. Under certain specific conditions, it may be possible for a remote attacker to trigger this race condition and cause such an application to crash, or possibly execute arbitrary code with the permissions of the application. (CVE-2010-3864)

Note, this issue does not affect the Apache HTTP Server. Refer to Red Hat Bugzilla bug 649304 for more technical details on how to determine if your application is affected.

This update is recommended to all OpenSSL users. For the update to take effect, all services linked to the OpenSSL library must be restarted, or the system rebooted.

This update is available via the Red Hat Network. Details on how to use the Red Hat Network to apply this update are available at http://kbase.redhat.com/faq/docs/DOC-11259

Mr. Rob Hulswit has reported this bug to Red Hat.