[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 May 2014 11:46:32 +0200
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Security release for mod_wsgi (version 3.5)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So CVEs were assigned, this is now public, very well written an
detailed write up is at:
http://blog.dscpl.com.au/2014/05/security-release-for-modwsgi-version-35.html
The Apache/mod_wsgi module I authored has been in suspended animation
for some time. Today though I announce a new release (version 3.5) to
address a security vulnerability, plus bring overdue updates to
address issues in support for Apache 2.4 and Python 3.4.
Version 3.5 of mod_wsgi can be downloaded from github at:
https://github.com/GrahamDumpleton/mod_wsgi/releases
The release notes for version 3.5 of mod_wsgi can be found at:
http://modwsgi.readthedocs.org/en/latest/release-notes/version-3.5.html
Although the security vulnerability will not affect all users, it is
highly recommended you upgrade to this new version, or any newer
revision of a Linux distributions binary package which includes a back
ported fix for the issue.
In addition to the details of this vulnerability, I also include here
details of an issue which was previously fixed in mod_wsgi 3.4 but was
recently also discovered to be more severe than previously believed
and which itself constitutes a security issue.
For more details read on. I will follow up this post with a further
post about the general future of the mod_wsgi module for Apache.
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.
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993
A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTfHX4AAoJEBYNRVNeJnmTYd0QAI3h2HN+VbmAY+gMow+IU7pY
3QJMQNSm2p8q8PKnOqjZZZQiMOklxARbPKW9EefAB4QoDca/7m+sl6Zrbmn3dv52
cMskIfOZ/530W9hF21s+KsVhbLemQv97MIidmZZkY//BghH8l6jhaYXQx7OJkgWS
zcnUs59srkSMKlTV0nww//pULbmJ2AK7ZuxBOqpsxUpqgTugCuyhFj0GwTljggIm
93q/IoDesZApMqfbBgkUcfUGj/EjDqM8LR5TUy6KqTnh8iulgdaakK25+e9lu9WL
X555y5wZzI15Nqniijoi16DhuF05b7JRRGVQboGbF2MbPz6WZQk+pvPh8SxBSIqG
1PzVp2/BcUyzfCp7oZWqbMj9UrBLn9O4i8OwQ/dR3yf72bWHBe+xMM933Xv2yuQL
dn7msHoMc72VDu/KxWWlfSbczdg8xEGX4yRvvuWwuXI6Sp3kWfU2Ggqqcwo8VgJw
395KSUCVf1uyYDOE530ptl6ShnYTLQ76p3ZmSl9I6x2iBgRgWn6P6gov8262M8WA
SQxRUhhReqjqqfUIpRxjhJBZxcn9W0lCUDVWqbO8AxEpOLk41g5Y4YWQlh0QFOhK
2R+G+WWaDUPLu12+guTA/OEo8QD0A7RlizNOl79+IMyFhcJFxPLusGY5IDUK+mwb
ij8EJjA0ebrOMrHKwF8J
=CWJw
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
