Security releases (CVE-2014-4931): Symfony 2.3.18, 2.4.8, and 2.5.2 released

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 _locale argument 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.

If you have found a security issue in Symfony, please send the details to security [at] symfony.com and don't disclose it publicly until we can provide a fix for it.

Comments

I updated but the Security Checker is still flagging 2.5.2 with the same vulnerability:

Security Report
===============

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.

symfony/symfony (v2.5.2)
------------------------

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
##############

'{% trans from "settingCampaign" %}Advertiser:{% endtrans %}'+
'{{ form_widget(form.advertiserId) }}'+
''+

###############
in 2.3.17 :
###############

'Advertiser:'+
''+
''+

###############
in 2.3.18 :
###############

'Advertiser:'+
'
'+
''+
@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.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.