XSRF CVE in tornado 2.2.1

[opoplawski]

We believe that tornado 2.2.1 in EPEL6 is vulnerable to the XSRF CVE - bug is filed here:

https://bugzilla.redhat.com/show_bug.cgi?id=1222820

I made a quick attempt to backport the 3.2.2 fix (attached to bug report), but it does not look good. I'm hoping for a little help/advice from upstream. Perhaps updating to a somewhat newer tornado in EPEL6 first would be good, but we can't break API. Any suggestions?

[bdarnell]

The bugzilla page links to https://bugzilla.redhat.com/attachment.cgi?id=1030781&action=diff, which includes changes to the release notes, web_test.py, util.py, and websocket.py, but not web.py. Unless I'm misinterpreting things and there is another diff involved, it looks like you missed the main part of the change, which was in web.py.

I don't think there were any relevant changes to cookie handling between 2.2.1 and 3.2.2, so the diff should apply more or less cleanly. While you're applying the XSRF cookie changes in 3.2.2 you'll also want to pick up the signed cookie fixes from 3.2.1. These cookie changes are interesting from a backwards-compatibility perspective: they're API-compatible with the previous release, but they're still disruptive because deploying them will invalidate any existing cookies (applications will have to opt-in to cookie versioning to avoid disruption).

I would encourage you to upgrade to a more current release of Tornado but I don't think it would make a difference for this issue. A high-level summary: 2.3 and 2.4 are low-risk upgrades. 3.0 removed some deprecated features (including support for python 2.5), and 4.0 made some changes to thread-safety semantics (although I think the things that changed in 4.0 were new in 3.0, so you might be fine to jump straight to 4.x if you're crossing the 3.0 boundary).

[bdarnell]

Please let me know if there is anything else I can help with here.