Symfony 2.0.25, 2.1.13, 2.2.9, and 2.3.6 have just been released; they contain a security fix for the Security component (CVE-2013-5958).

Note

Even if the end of life of Symfony 2.0 was reached last month, we are also releasing a new version for 2.0. Symfony 2.1 is also out of maintenance, but we are still releasing new versions for security fixes until the end of November 2013. Read our release policy for more information.

A couple of weeks ago, I published a post about a vulnerability in FOSUserBundle. Besides the fix in the bundle, I've also added an additional safeguard to the encoders in the master branch (for the upcoming 2.4 version).

But as noticed by Christophe Coevoet, the fix from the master branch should also have been merged in older branches as the login form handling is done by the framework itself, not by the user code.

Affected versions

All 2.0.X, 2.1.X, 2.2.X, and 2.3.X versions of the Security component are affected by this issue.

Description

One of the best practices for passwords is to store a hash of the password instead of the raw value. In Symfony, the encoders are responsible for the hash creation (when a user creates an account) and verification (when a user tries to log in).

For most built-in encoders, the time is takes to compute a hash increases significantly with the length of the password. If an attacker submits random large passwords repeatedly, Symfony will be forced to do expensive computation, which can be used to ease a DOS attack.

All encoders are not vulnerable, but the recommended ones are. For information, here are the times it takes to encode a password of 1 million characters (lines with a * denotes the built-in encoder default configurations):

Encoder encodePassword()
BCrypt (cost <14) <1s
BCrypt (cost 18) 20s
BCrypt (cost 20) 78s
Pbkdf2* (1,000 it) 6s
Plaintext* <1s
MessageDigest* (5,000 it) 30s
Pbkdf2 (10,000 it) 55s

As you can see, for the `Pbkdf2` encoder, it takes almost one minute when the number of iterations is set to `10,000` (which is the number of iterations used in iOS 7.)

Resolution

The password length for a user account must have a maximum length to mitigate the attack. When a user enters or modifies a password on your website, check that you have set a max length constraint. If you are using FOSUserBundle, the fix was done a couple of weeks ago.

When the user tries to login on your website, the logic is handled by the framework itself, and as such, it must also restrict the maximum length of the password it accepts before encoding it. The patch we made on today's releases consists of rejecting any password larger than 4096 characters. Both the encodePassword() and isPasswordValid() methods of the built-in encoders enforce this limit.

If you use a custom encoder, you need to check the password length with the $this->isPasswordTooLong($raw); method yourself (have a look at the built-in encoders implementation).

You need to upgrade Symfony to its latest version, according to the branch you are using for your project, or you can apply the following patches:

Tip

To be notified about important Symfony dates, consider subscribing to the roadmap notifications.

Tip

You can check if your project is up-to-date with the latest security patches by using the SensioLabs Security Advisories Checker.

Published in #Releases #Security Advisories