Skip to content

2.1.1 (2014-07-29) - Security Fix - Please update NOW!

Compare
Choose a tag to compare
@willdurand willdurand released this 29 Jul 09:35
· 149 commits to master since this release

This is a security release. All users MUST upgrade to this release to prevent two potential security issues:

  • path traversal attack
  • remote code injection

These two security issues have been reported by Andreas Forsblom. THANKS!

Below is the original report Andreas sent me:

Hi William,

First, thank you for a very useful bundle :)

Unfortunately, while investigating if a Symfony project I'm working on was vulnerable to the recent translation-related Symfony security issue (CVE-2014-4931), fixed in Symfony 2.5.2, I discovered that JsTranslationBundle seems to be vulnerable to a unrelated path traversal attack, and potentially also a js injection attack.

---

If I try to retrieve the translations using the following url:

http://localhost/translations?locales=randomstring/something

the file something.js gets created in the subdirectory messages.randomstring of the cache directory:

/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/something.js

(this is the actual string that gets passed to the constructor of ConfigCache by the JsTranslationBundle controller)

I can now traverse down from the JsTranslationBundle cache directory (without first creating the "messages.randomstring" directory using the previous step, this won't work):

http://localhost/translations?locales=randomstring/../../evil

becomes

/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/../../evil.js

... and depending on the configuration of the server, I could also do
http://localhost/translations?locales=randomstring/../../../../../web/evil

=>

/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/../../../../../web/evil.js

thus creating the file evil.js (and evil.js.meta) under the Symfony web root. Depending on file system permissions, this will also overwrite existing files.


---


Again depending on the server configuration, it also seems to be possible to inject actual JavaScript code:

http://localhost/translations?locales=foo%0Auncommented%20code;

=>

(function (Translator) {
    Translator.fallback      = 'en';
    Translator.defaultDomain = 'messages';
    // foo
uncommented code;
})(Translator);

This works on some systems I tried, but not others. I suspect it might be related to the character set configuration, but I haven't investigated it further yet.


---

I did my testing using JsTranslationBundle 2.1.0 and Symfony 2.5.2.

Since this is a security issue, I didn't want to submit a pull request or use the GitHub issue tracker.

Three commits fixed these issues: df6c0fd, 7accee9, and 6ee06b9.

You will find three patch files below in case you can't easily upgrade to this release.

Changelog

  • Fixed: hange test related to path traversal attack
  • Fixed: potential code injection via locale parameter
  • Added: test to prove a path traversal attack
  • Added: HHVM support in travis-ci