| Summary: | <www-apache/mod_wsgi-3.5: two vulnerabilities (CVE-2014-{0240,0242}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | djc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2014/05/21/1 | ||
| Whiteboard: | B1 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
3.5 is in the tree. Arches, please stabilize. Arches, please test and mark stable: =www-apache/mod_wsgi-3.5 Target Keywords : "amd64 ppc x86" Thank you! amd64 stable ppc stable x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. Cleanup done. Arches and Maintainer(s), Thank you for your work. New GLSA Request filed. CVE-2014-0240 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0240): The mod_wsgi module before 3.5 for Apache, when daemon mode is enabled, does not properly handle error codes returned by setuid when run on certain Linux kernels, which allows local users to gain privileges via vectors related to the number of running processes. This issue was resolved and addressed in GLSA 201412-21 at http://security.gentoo.org/glsa/glsa-201412-21.xml by GLSA coordinator Sean Amoss (ackle). |
From ${URL} : Issue: Possibility of local privilege escalation when using daemon mode. (CVE-2014-0240) The issue is believed to affect Linux systems running kernel versions > = 2.6.0 and < 3.1.0. The issue affects all versions of mod_wsgi up to and including version 3.4. The source of the issue derives from mod_wsgi not correctly handling Linux specific error codes from setuid(), which differ to what would be expected to be returned by UNIX systems conforming to the Open Group UNIX specification for setuid(). http://man7.org/linux/man-pages/man2/setuid.2.html http://pubs.opengroup.org/onlinepubs/009695399/functions/setuid.html This difference in behaviour between Linux and the UNIX specification was believed to have been removed in version 3.1.0 of the Linux kernel. https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/u6cKf4D1D-k The issue would allow a user, where Apache is initially being started as the root user and where running code under mod_wsgi daemon mode as an unprivileged user, to manipulate the number of processes run by that user to affect the outcome of setuid() when daemon mode processes are forked and so gain escalated privileges for the users code. Due to the nature of the issue, if you provide a service or allow untrusted users to run Python web applications you do not control the code for, and do so using daemon mode of mod_wsgi, you should update mod_wsgi as soon as possible. If you are unable to upgrade to a newer version of mod_wsgi, but wish to back port the fix to an older version of mod_wsgi that you are using, then the patch from mod_wsgi 3.5 can be found at: https://github.com/GrahamDumpleton/mod_wsgi/commit/d9d5fea585b23991f76532a9b07de7fcd3b649f4 There is no workaround for this issue, so using a version of mod_wsgi which incorporates the fix is your only choice. Thanks go to R�bert Kisteleki for identifying this issue. Issue: Possibility of information disclosure via Content-Type response header. (CVE-2014-0242) The issue was actually identified and previously fixed in version 3.4 (August 2012) of mod_wsgi. Response Content-Type header could be corrupted when being sent in multithreaded configuration and embedded mode being used. Problem thus affected Windows and worker MPM on UNIX. Release notes for version 3.4 of mod_wsgi can be viewed at: http://modwsgi.readthedocs.org/en/latest/release-notes/version-3.4.html At the time it was believed to be relatively benign, only ever having been seen with one specific web application (Trac - http://trac.edgewall.org), with the corrupted value always appearing to be replaced with a small set of known values which themselves did not raise concerns. A new example of this problem has now been identified which opens this issue up as being able to cause arbitrary corruption of the web server HTTP response Content-Type value, resulting in possible exposure of data from the hosted web application to a HTTP client. The new example also opens the possibility that the issue can occur with any Apache MPM and not just multithreaded MPMs as previously identified. Albeit that it still requires some form of background application threads to be in use, when a single threaded Apache MPM is being used. In either case, it is still however restricted to the case where embedded mode of mod_wsgi is being used. The specific scenario which can trigger the issue is where the value for the Content-Type response header is dynamically generated, and where the stack frame where the calculation was done went out of use between the time that the WSGI start_response() function was called and the first non empty byte string was yielded from the WSGI application for the response, resulting in the Python object being destroyed and memory returned to the free list. At the same time, it would have been necessary for a parallel request thread or an application background thread to execute during that window of time and perform sufficient object allocations so as to reuse the memory previously used by the value of the Content-Type response header. Example code which can be used to trigger the specific scenario can be found at: https://gist.github.com/GrahamDumpleton/14b31ebe18166a89b090 That example code also provides a workaround if you find yourself affected by the issue but cannot upgrade straight away. It consists of the @intern_content_type decorator/wrapper. This can be applied to the WSGI application entry point and will use a cache to store the value of the Content-Type response header to ensure it is persistent for the life of the request. If you are still using a version of mod_wsgi older than version 3.4, but are unable to upgrade to a newer version of mod_wsgi and wish to back port the fix to the older version of mod_wsgi that you are using, then the patch from mod_wsgi 3.4 can be found at: https://github.com/GrahamDumpleton/mod_wsgi/commit/b0a149c1f5e569932325972e2e20176a42e43517 Thanks go to Buck Golemon for identifying this subsequent issue. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.