Security releases (CVE-2013-5958): Symfony 2.0.25, 2.1.13, 2.2.9, and 2.3.6 released
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).
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.
All 2.0.X, 2.1.X, 2.2.X, and 2.3.X versions of the Security component are affected by this issue.
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
|BCrypt (cost <14)||<1s|
|BCrypt (cost 18)||20s|
|BCrypt (cost 20)||78s|
|Pbkdf2* (1,000 it)||6s|
|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.)
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
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:
- Download the patch for Symfony 2.0;
- Download the patch for Symfony 2.1;
- Download the patch for Symfony 2.2;
- Download the patch for Symfony 2.3;
To be notified about important Symfony dates, consider subscribing to the roadmap notifications.
You can check if your project is up-to-date with the latest security patches by using the SensioLabs Security Advisories Checker.
Have found a security issue in Symfony? Send the details to security [at] symfony.com and don't disclose it publicly until we can provide a fix for it.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
And you should also add it in the appropriate section of the documentation.