Robbie
on 16 October 2014
The following is an update on Ubuntu’s response to the latest Internet emergency security issue, POODLE (CVE-2014-3566), in combination with an
SSLv3 downgrade vulnerability.
Vulnerability Summary
“SSL 3.0 is an obsolete and insecure protocol. While for most practical purposes it has been replaced by its successors TLS 1.0, TLS 1.1, and TLS 1.2, many TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. The protocol handshake provides for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used.” –https://www.openssl.org/~bodo/ssl-poodle.pdf
A vulnerability was discovered that affects the protocol negotiation between browsers and HTTP servers, where a man-in-the-middle (MITM) attacker is able trigger a protocol downgrade (ie, force downgrade to SSLv3, CVE to be assigned). Additionally, a new attack was discovered against the CBC block cipher used in SSLv3 (POODLE, CVE-2014-3566). Because of this new weakness in the CBC block cipher and the known weaknesses in the RC4 stream cipher (both used with SSLv3), attackers who successfully downgrade the victim’s connection to SSLv3 can now exploit the weaknesses of these ciphers to ascertain the plaintext of portions of the connection through brute force attacks. For example, an attacker who is able to manipulate the encrypted connection is able to steal HTTP cookies. Note, the protocol downgrade vulnerability exists in web browsers and is not implemented in the ssl libraries. Therefore, the downgrade attack is currently known to exist only for HTTP.
OpenSSL will be updated to guard against illegal protocol negotiation downgrades (TLS_FALLBACK_SCSV). When the server and client are updated to use TLS_FALLBACK_SCSV, the protocol cannot be downgraded to below the highest protocol that is supported between the two (so if the client and the server both support TLS 1.2, SSLv3 cannot be used even if the server offers SSLv3).
The recommended course of action is ultimately for sites to disable SSLv3 on their servers, and for browsers to disable SSLv3 by default since the SSLv3 protocol is known to be broken. However, it will take time for sites to disable SSLv3, and some sites will choose not to, in order to support legacy browsers (eg, IE6). As a result, immediately disabling SSLv3 in Ubuntu in the openssl libraries, in servers or in browsers, will break sites that still rely on SSLv3.
Ubuntu’s Response:
Unfortunately, this issue cannot be addressed in a single USN because this is a vulnerability in a protocol, and the Internet must respond accordingly (ie SSLv3 must be disabled everywhere). Ubuntu’s response provides a path forward to transition users towards safe defaults:
- Add TLS_FALLBACK_SCSV to openssl in a USN: In progress, upstream openssl is bundling this patch with other fixes that we will incorporate
- Follow Google’s lead regarding chromium and chromium content api (as used in oxide):
- Add TLS_FALLBACK_SCSV support to chromium and oxide: Done – Added by Google months ago.
- Disable fallback to SSLv3 in next major version: In Progress
- Disable SSLv3 in future version: In Progress
- Follow Mozilla’s lead regarding Mozilla products:
- Disable SSLv3 by default in Firefox 34: In Progress – due Nov 25
- Add TLS_FALLBACK_SCSV support in Firefox 35: In Progress
Ubuntu currently will not:
- Disable SSLv3 in the OpenSSL libraries at this time, so as not to break compatibility where it is needed
- Disable SSLv3 in Apache, nginx, etc, so as not to break compatibility where it is needed
- Preempt Google’s and Mozilla’s plans. The timing of their response is critical to giving sites an opportunity to migrate away from SSLv3 to minimize regressions
For more information on Ubuntu security notices that affect the current supported releases of Ubuntu, or to report a security vulnerability in an Ubuntu package, please visit http://www.ubuntu.com/usn/.
