[ANN] Ring 1.0.3 / 1.1.7 released to fix security flaw

Showing 1-1 of 1 messages
[ANN] Ring 1.0.3 / 1.1.7 released to fix security flaw James Reeves 1/12/13 3:34 PM
There is a vulnerability in the ring.middleware.session.cookie namespace that affects Ring sites using the cookie session store.

Versions affected: 1.0.0 to 1.1.6

Fixed versions: 1.0.3, 1.1.7

Overview

In order for an attacker exploit this flaw, your site must be using the cookie session store, and the attacker must have gained the capability to change the stored session string.

If your application's session is compromised in this manner, then the attacker can use this vulnerability to execute arbitrary expressions in Clojure.

This flaw does not allow an attacker to compromise a site from scratch.

Attack Vectors

The attacker needs to be able to rewrite the serialised session string that's stored in an encrypted cookie. There are two methods of doing this:

1. Discover the secret key used to encrypt the cookie.
2. Trick the application into writing an insecure value to the session. (Confused Deputy attack)

In particular the second method may apply to your application if you are converting user data into a keyword or symbol, and then writing it to the session. This is because the keyword and symbol functions do not check for forbidden characters such as spaces.

As part of this fix for this issue, versions 1.0.3 and 1.1.7 of Ring contain an additional check to ensure that the session data is valid before writing it.

Cause

This vulnerability is caused by the use of read-string to read the decrypted session data without first setting *read-eval* to false. This means that if an attacker can write an arbitrary string to the session, they can use the #=() form to evaluate an expression.

This could be used to make a bad security breach worse, but cannot be used to compromise a secure application.

Recommendation

Upgrade to 1.0.3 or 1.1.7 if you are using the cookie session store.

Credit

Thank you to Lou Franco for discovering this security flaw, and his responsible disclosure of it. Thanks as well go to Mark McGranaghan, Phil Hagelberg and Chas Emerick for looking into this issue.