Bug 1222816 (CVE-2014-9720) - CVE-2014-9720 python-tornado: XSRF cookie allows side-channel attack against TLS (BREACH)
Summary: CVE-2014-9720 python-tornado: XSRF cookie allows side-channel attack against ...
Alias: CVE-2014-9720
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1222820 1222819
Blocks: 1222818
TreeView+ depends on / blocked
Reported: 2015-05-19 08:53 UTC by Vasyl Kaigorodov
Modified: 2019-09-29 13:32 UTC (History)
6 users (show)

Fixed In Version: python-tornado 3.2.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-12 08:23:14 UTC

Attachments (Terms of Use)

Description Vasyl Kaigorodov 2015-05-19 08:53:05 UTC
From http://www.tornadoweb.org/en/stable/releases/v3.2.2.html

Security fixes

    The XSRF token is now encoded with a random mask on each request. This makes it safe to include in compressed pages without being vulnerable to the BREACH attack. This applies to most applications that use both the xsrf_cookies and gzip options (or have gzip applied by a proxy).

Backwards-compatibility notes

    If Tornado 3.2.2 is run at the same time as older versions on the same domain, there is some potential for issues with the differing cookie versions. The Application setting xsrf_cookie_version=1 can be used for a transitional period to generate the older cookie format on newer servers.

Upstream patch:

Comment 1 Vasyl Kaigorodov 2015-05-19 08:55:29 UTC
Created python-tornado tracking bugs for this issue:

Affects: fedora-all [bug 1222819]
Affects: epel-all [bug 1222820]

Comment 2 Fedora Update System 2015-06-09 15:04:23 UTC
python-tornado-3.2.2-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 3 Fedora Update System 2015-06-10 19:18:19 UTC
python-tornado-3.2.2-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 4 Ján Rusnačko 2015-08-12 08:20:45 UTC

BREACH attack misuses the interaction between compression and encryption to extract secrets from encrypted message. If attacker can control part of the message being encrypted, which contains a secret, he could observe lengths of encrypted messages to infer which strings were present in the message before compression, with the idea that message containing multiple occurrences of some substring should be compressed more efficiently.

Given the scenario where client sends a HHTP request M to the server containing secret S (CSRF token) and
* attacker can inject strings into message M *before* S appears
* attacker can observe length of the encrypted request

then attacker can start iterating over all possible strings P and constructing M=a + P + b + S + c, where a,b,c are any data, and observing the length of the compressed and encrypted message.

If the secret S contains string P, compression algorithm will output shorter message, than in the case S does not contain P. By iterating over all P, attacker can infer from the length of compressed and encrypted requests which string P are contained in S, thus revealing the secret.

The fix for this flaw masks secret S (CSRF) token by XORing it with random string. This prevents BREACH attack, because every request now contain string S'=S xor R, which is different for every message, instead of a fixed secret S.

External references:

Note You need to log in before you can comment on or make changes to this bug.