distribute uwsgi 1.2.6 or newer on all supported Ubuntu releases

Bug #1225668 reported by Louis-Dominique Dubeau on 2013-09-15
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
uwsgi (Ubuntu)
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Undecided
Unassigned

Bug Description

Django has added the following warning to their documentation:

"Some distributions, including Debian and Ubuntu, ship an outdated version of uWSGI that does not conform to the WSGI specification. Versions prior to 1.2.6 do not call close on the response object after handling a request. In those cases the request_finished signal isn’t sent. This can result in idle connections to database and memcache servers."

I ran into a problem in a Django application hosted on Ubuntu 12.04.3. I've discovered that due to the problem mentioned in Django's documentation, transactions in a mysql database would persist from Django request to Django request. The problem was the due to the bug in uwsgi, Django's response objects would never close and Django would never do its cleanup.

Security wise, the upshots are:

1. A database administrator *revoking* database permissions through an application provided by uwsgi might not be able to get changes to the database to stick, because the transaction in which the changes are made is not completed until indeterminate time T. (I've seen this happen with my own eyes.) These changes could even be rolled back because a piece of code which happens to run in the same transaction as the one which changed the permissions decides to roll back, and thus the revoked permissions are never revoked.

2. This could lead to a denial of service, because database locks or other resources could be held for some random amount of time.

This problem is not peculiar to Django. Any substantial application getting served through uwsgi is vulnerable. The WSGI specs (http://www.python.org/dev/peps/pep-0333/) state that:

"If the iterable returned by the application has a close() method, the server or gateway must call that method upon completion of the current request, whether the request was completed normally, or terminated early due to an error. (This is to support resource release by the application. This protocol is intended to complement PEP 325's generator support, and other common iterables with close() methods."

(Unbalanced parentheses in the original.)

Jamie Strandboge (jdstrand) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

Changed in uwsgi (Ubuntu):
status: New → Incomplete
information type: Private Security → Public Security
Colin Watson (cjwatson) wrote :

Fixed in saucy and newer, judging from version numbers; precise/quantal/raring are apparently still vulnerable.

Changed in uwsgi (Ubuntu):
status: Incomplete → Fix Released
Changed in uwsgi (Ubuntu Raring):
status: New → Won't Fix
Changed in uwsgi (Ubuntu Quantal):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers