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 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 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 found here:
http://code.djangoproject.com/svn/django/trunk/django/bin/compile-messages.py
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:
http://code.djangoproject.com/changeset/3592
If you're interested in how we fixed the error, see the excellent
document "String replacements in command lines":
http://cyberelk.net/tim/articles/cmdline/ar01s02.html .
Thanks to Rene Dudfield for reporting this.
-The Django team
(Cross-posted to django-announce, django-i18n, django-developers and
django-users. We recently created the django-announce mailing list but
it isn't yet well-known -- hence the wide net of mailing lists.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django I18N" group.
To post to this group, send email to Django-I18N@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/Django-I18N
-~----------~----~----~----~------~----~------~--~---
