Symfony 2.3.18, 2.4.8, and 2.5.2 have just been released; they contain a security fix for the Translator class provided by FrameworkBundle (CVE-2014-4931).
Note
The Symfony versions released today also contain a server-side mitigation for a JSONP vulnerability as described in CVE-2014-4671. You can learn more about this at Abusing JSONP with Rosetta Flash. Also, if you are using NelmioSecurityBundle, disable the content type sniffing for script resources.
Affected versions
All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the FrameworkBundle coming from the Symfony full-stack framework are affected by this issue. The translator component by itself is not vulnerable.
Note
We do not provide new versions of Symfony 2.0, 2.1, and 2.2 anymore as they reached their end of life; if you really need to patch those versions, use the patch for Symfony 2.3.)
Description
When investigating issue #11093, Jeremy Derussé found a serious code injection issue in the way Symfony implements translation caching in FrameworkBundle.
Your Symfony application is vulnerable if you meet the following conditions:
- You are using the Symfony translation system from FrameworkBundle (so basically if you are using Symfony full-stack -- you are not affected if you are using the Translation component with Silex for instance);
- You don't sanitize locales coming from a URL (any route with a
_localeargument for instance):
When vulnerable, an attacker can submit a non-valid locale value that can contain some PHP code that will be executed by Symfony. That's because the locale value is dumped into a PHP file generated in the cache without being sanitized first.
Resolution
This patch solves the issue by rejecting locales that contain characters outside the range of valid ones for locales. Symfony does not validate the locale as someone can create any locale name if he wants to. So, this patch makes everything secure without breaking BC (except if the developer uses a locale with "strange" characters, but I doubt it's that widespread.)
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 patche: https://github.com/symfony/symfony/commit/06a80fbdbe744ad6f3010479ba64ef5cf35dd 9af.patch
Credits
I would like to thank Jeremy Derussé for reporting this security issue and for providing a patch.
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, or by using SensioLabsInsight.
I updated but the Security Checker is still flagging 2.5.2 with the same vulnerability:
The checker detected 1 package(s) that have known* vulnerabilities in your project. We recommend you to check the related security advisories and upgrade these dependencies.
CVE-2014-4931: Code injection in the way Symfony implements translation caching in FrameworkBundle http://symfony.com/blog/security-releases-cve-2014-4931-symfony-2-3-18-2-4-8-and-2-5-2-released
There is a typo: Symfony 2.3.17, 2.4.7, and 2.5.2 have just been released should be : Symfony 2.3.18, 2.4.8, and 2.5.2 have just been released
Alex, there was a problem in the security advisories database which has been fixed now.
I think there is a typo in the ID of the vulnerability: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4931 - not found
is this CVE related to the CNET hack?
@Lukas No, it's not.
Is the JMSi18nRoutingBundle usage of the locale parameter affected by this vulnerability?
Updated with 2.3.18 : Changements in form widgets generate some issue in my project. I have javascript error now. Because you have added break line in html form. So we can't update to 2.3.18. We have to update all our twig views.
############## twig view ##############
'
'+ '{{ form_widget(form.advertiserId) }}'+ '
'+############### in 2.3.17 : ###############
'
'+ ''+ '
'+############### in 2.3.18 : ###############
'
'+ '
'+ ''+@Fabien do you know what was the root cause in CNET's case? I guess the entire Symfony2 community is interested in their security whole and how to prevent it.
+1
I haven't been able to find any real details on the CNET compromise. Was it a current version of Symfony? Old version that ignored a security advisory? Something not yet understood and addressed?
Reading the CVE once more, I am left unsure that the impact is. Does this only allow someone to generate lots of bogus cache files, filling up the disc? Or does it allow someone to forge a locale that would allow them to somehow read files from the disc?
@lsmith the CVE concerning this Symfony issue is still not available (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4931) .
The link given par Fabien concerns an other PR (https://github.com/symfony/symfony/pull/11367) merged and released in the same version.
To answer to your question, this issue belongs to the "Code Injection" familly.
@radutopala, @twencl CNET does not use locale in route, it's probably not related to this issue. BTW they also deploy app_dev.php in production and remove the IP check (https://twitter.com/lucas_courot/status/489148134560649216)
@Jérémy I was talking about the sanitization issue with the translation system. The JSONP issue was clear to me, however it was also not detailed here. I really think we should not skimp on providing details here about the impact of security issues. Hackers will spend the time to figure this out or will not be able, the average developer will not and may scramble to do an update that is not needed or skip an update that would spare them from being hacked.