Weblog

Small security hole fixed in translation helper utility

The Django team discovered and fixed a small security hole in the django/bin/compile-messages.py helper script, which is the script that compiles language translation message files (.po files) into binary format (.mo files).

The compile-messages.py script uses the name of the .po file to build arguments to a system command, and it didn't sufficiently validate the filename for potentially malicious content.

Users who relied on the language translation files provided with Django, or who wrote and compiled their own translations, were never at risk. Users who never ran the compile-messages.py script were never at risk. Only users who compiled third-party translations without examining the filenames first were potentially vulnerable.

No exploit based on this vulnerability, proof-of-concept or otherwise, is known to have existed.

Due to the nature of the vulnerability, we do not feel this merits a new release of Django. However, users who rely on third parties to supply translation files -- such as Django's own i18n maintainers -- are encouraged either to patch their code in one of these ways:

  • Upgrade to the latest Django trunk (the Django development version).
  • Simply overwrite your copy of django/bin/compile-messages.py with the new version. This file has not changed in any backwards-incompatible way since before Django version 0.90, so it's safe to copy over, regardless of which Django version you're using.
  • We've applied the patches to Subversion "bug-fix" branches for both previous Django versions, 0.90 and 0.91. You can access those branches here:

    • svn co http://code.djangoproject.com/svn/django/branches/0.90-bugfixes
    • svn co http://code.djangoproject.com/svn/django/branches/0.91-bugfixes

If none of those solutions is possible, we strongly encourage users to examine the names of translation files carefully before compiling them. Of course, the same standards should be applied when examining translation files from untrusted third parties as would be applied to any code received from an untrusted source.

(All users are advised, as always, to keep in mind the risks of using any file from a third-party source, and to carefully examine any third-party code before executing it.)

This security hole was fixed in changeset 3592. The patch is available here.

If you're interested in how we fixed the error, see the excellent document String replacements in command lines.

Thanks to Rene Dudfield for reporting this.

Posted by Adrian Holovaty on August 16, 2006