Security updates released
In accordance with our security policy, today the Django project is issuing a set of releases to remedy a vulnerability reported to us. This announcement contains a description of the vulnerability, a description of the changes made to fix it, and pointers to the patches for each supported version of Django.
Also covered here is an unrelated issue which, though security-related and resulting in changes to future Django releases, is not being treated as a vulnerability in Django itself.
Description of vulnerability
Django includes a lightweight, WSGI-based web server for use in learning Django and in testing new applications during early stages of development. For sake of convenience, this web server automatically maps certain URLs corresponding to the static media files used by the Django administrative application.
The handler which maps these URLs did not properly check the requested URL to verify that it corresponds to a static media file used by Django. As such, a carefully-crafted URL can cause the development server to serve any file to which it has read access.
By default, the development server does not listen on interfaces other than the local IPv4 loopback, and Django's documentation has and will continue to have stern warnings against the use of the development server in other situations (e.g., listening on a publicy- or network-accessible interface), and stating that the development server is not considered secure or performant enough for such use.
Affected versions
- Django development trunk
- Django 1.0
- Django 0.96
Resolution
The development server's admin media handler has been patched to verify that the requested URL corresponds to a static media file which should be served, and to properly emit an HTTP 404 ("File Not Found") response when the URL does not correspond to such a file.
Patches were applied in the following changesets:
- Django development trunk: changeset 11351
- Django 1.0.X release series: changeset 11353.
- Django 0.96.X release series: changeset 11354.
The following releases are being issued immediately:
These releases are strongly encouraged upgrades for all users of affected versions of Django.
The final release of Django 1.1, due within hours of these releases, will include the above patch from the development trunk.
Secondary issue
A common deployment strategy for Django in some types of hosting environments involves placing the server which handles Django behind some other web server, which then acts as an HTTP proxy. In such situations, the REMOTE_ADDR environment variable is typically the IP address of the proxy. For convenience, Django includes an optional middleware class -- django.middleware.http.SetRemoteAddrFromForwardedFor -- which updates the value of REMOTE_ADDR based on the HTTP X-Forwarded-For header commonly set by some proxy configurations.
It has been demonstrated that this mechanism cannot be made reliable enough for general-purpose use, and that (despite documentation to the contrary) its inclusion in Django may lead application developers to assume that the value of REMOTE_ADDR is "safe" or in some way reliable as a source of authentication.
While not directly a security issue (since relying on REMOTE_ADDR or similar values is widely known to be a worst practice), the Django team has decided to deprecate and begin the process of removing this middleware with the Django 1.1 release.
This middleware class will be left as-is in the 1.0 and 0.96 release series, but in the 1.1 release series it will be replaced with a class which takes no action other than raising a deprecation error. It is expected that this placeholder warning class will be removed in the Django 1.2 release series.
Miscellaneous
Please note that the release of Django 1.1 will trigger end-of-life for the Django 0.96 release series; as such, Django 0.96.4 will be the last official release in that series and it will no longer receive bugfix or security support directly from the Django development team.
