CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine. Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f running on Intel Sandy Bridge processors after observing only 16,000 secret-key operations (decryption, signatures).
https://ssrg.nicta.com.au/projects/TS/cachebleed/
Posted from WordPress for Android
3 Comments
Tomi Engdahl says:
CacheBleed: A Timing Attack on OpenSSL Constant Time RSA
https://ssrg.nicta.com.au/projects/TS/cachebleed/
CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine. Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f running on Intel Sandy Bridge processors after observing only 16,000 secret-key operations (decryption, signatures). This is despite the fact that OpenSSL’s RSA implementation was carefully designed to be constant time in order to protect against cache-based (and other) side-channel attacks.
While the possibility of an attack based on cache-bank conflicts has long been speculated, this is the first practical demonstration of such an attack. Intel’s technical documentation describes cache-bank conflicts as early as 2004. However, these were not widely thought to be exploitable, and as a consequence common cryptographic software developers have not implemented countermeasures to this attack.
Tomi Engdahl says:
Other OpenSSL issues:
OpenSSL Security Advisory [1st March 2016]
=========================================
https://www.openssl.org/news/secadv/20160301.txt
NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as
well as removing SSLv2 EXPORT ciphers. We strongly advise against the use of
SSLv2 due not only to the issues described below, but to the other known
deficiencies in the protocol as described at
https://tools.ietf.org/html/rfc6176
Recovering one session key requires the attacker to perform approximately 2^50
computation, as well as thousands of connections to the affected server. A more
efficient variant of the DROWN attack exists against unpatched OpenSSL servers
using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on
19/Mar/2015 (see CVE-2016-0703 below).
Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS
servers, if they’ve not done so already.
Divide-and-conquer session key recovery in SSLv2 (CVE-2016-0703)
================================================================
Severity: High
Note
====
As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are advised to
upgrade.
Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.
Tomi Engdahl says:
More info on openSSL issues:
Dan Goodin / Ars Technica:
13M+ HTTPS sites, email services using TLS protocol open to decryption attack, made possible due to weak ciphers added prior to 2000 as part of US export regs — More than 13 million HTTPS websites imperiled by new decryption attack — Low-cost DROWN attack decrypts data in hours, works against TLS e-mail servers, too.
More than 11 million HTTPS websites imperiled by new decryption attack
Low-cost DROWN attack decrypts data in hours, works against TLS e-mail servers, too.
http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/
The vulnerability joins a swarm of other critical bugs that over the past five years have given attackers the ability to break TLS. With names including BEAST, CRIME, BREACH, and FREAK, the proof-of-concept exploits have demonstrated dangerous holes in a protocol that’s the sole means for most websites and e-mail servers to encrypt and authenticate communications over an Internet that was never designed to be secure or private. TLS security hit a new low last May with the discovery of Logjam, a vulnerability caused by deliberately weakened cryptography that allowed eavesdroppers to read and modify data passing through tens of thousands of Web and e-mail servers. The researchers have dubbed the latest vulnerability DROWN, short for Decrypting RSA with Obsolete and Weakened eNcryption.
Dan Goodin / Ars Technica:
Over 13M HTTPS websites and email services using the TLS protocol vulnerable to new decryption attack, including over 97K of the top 1M most popular sites
More than 11 million HTTPS websites imperiled by new decryption attack
Low-cost DROWN attack decrypts data in hours, works against TLS e-mail servers, too.
http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/
More than 11 million websites and e-mail services protected by the transport layer security protocol are vulnerable to a newly discovered, low-cost attack that decrypts sensitive communications in a matter of hours and in some cases almost immediately, an international team of researchers warned Tuesday. More than 81,000 of the top 1 million most popular Web properties are among the vulnerable HTTPS-protected sites.
The attack works against TLS-protected communications that rely on the RSA cryptosystem when the key is exposed even indirectly through SSLv2, a TLS precursor that was retired almost two decades ago because of crippling weaknesses. The vulnerability allows an attacker to decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time. While many security experts believed the removal of SSLv2 support from browser and e-mail clients prevented abuse of the legacy protocol, some misconfigured TLS implementations still tacitly support the legacy protocol when an end-user computer specifically requests its use.
Recent scans of the Internet at large show that more than 5.9 million Web servers, comprising 17 percent of all HTTPS-protected machines, directly support SSLv2. The same scans reveal that at least 936,000 TLS-protected e-mail servers also support the insecure protocol. That’s a troubling finding, given widely repeated advice that SSLv2—short for secure sockets layer version 2—be disabled.