The latest version of Python supports hash randomization. http://mail.python.org/pipermail/python-list/2012-April/1290792.html For webapps deployed with mod_wsgi, it's not trivial to enable this feature to secure your webapp. I first attemped to fix this by modifying apache's init script (https://fedorahosted.org/fedora-infrastructure/ticket/3169). This approach is not ideal, because it adds Python-specific options to the init script, which tends to be distro-specific anyway. The ideal solution, IMO, is to add an option to mod_wsgi that enables hash randomization. I wrote a patch that adds a WSGIHashRandomization option, disabled by default, and sent it upstream. https://groups.google.com/group/modwsgi/browse_thread/thread/f8b71ca48a13e244/66147bfa3b359f06#66147bfa3b359f06
I have a specfile with this patch ready to go, but I would like to get +1's from our Python and mod_wsgi maintainers before I move forward with pushing this out.
EL-6 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3988758
(In reply to comment #1) > I have a specfile with this patch ready to go, but I would like to get +1's > from our Python Overall: +1 from me, but can we see the change to the mod_wsgi.spec also please? In particular, I think it needs a BuildRequires: python-devel >= 2.7.3 in order to pull in the version of python 2 with the hash randomization. > and mod_wsgi maintainers before I move forward with pushing this out.
lmacken: have you tested your mod_wsgi patch with a debug build of python (the python-debug package)? Specifically, a --with-pydebug build of python has some extra asserts about hash randomization initialization that a regular build doesn't have, to make sure everything happens in the correct order. Hopefully it will work, but it's worth checking that with your mod_wsgi patch that the hash initialization starts up in the order that those C asserts expect.
(In reply to comment #2) > EL-6 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3988758 BTW, looking in the x86_64's root.log: http://koji.fedoraproject.org/koji/getfile?taskID=3988760&name=root.log I see that the buildroot had python-devel-2.6.6-29.el6.x86_64 (which doesn't have the hash randomization). and the build.log e.g. on x86_64 has this: checking Python hash randomization support... no So this scratch build only tests the compat against older pythons lacking hash randomization.
(In reply to comment #4) > lmacken: have you tested your mod_wsgi patch with a debug build of python (the > python-debug package)? > > Specifically, a --with-pydebug build of python has some extra asserts about > hash randomization initialization that a regular build doesn't have, to make > sure everything happens in the correct order. > > Hopefully it will work, but it's worth checking that with your mod_wsgi patch > that the hash initialization starts up in the order that those C asserts > expect. I just tested with python-2.7.3-1.fc17.x86_64 + python-debug-2.7.3-1.fc17.x86_64, and everything worked as expected.
(In reply to comment #5) > (In reply to comment #2) > > EL-6 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3988758 > > BTW, looking in the x86_64's root.log: > http://koji.fedoraproject.org/koji/getfile?taskID=3988760&name=root.log > I see that the buildroot had python-devel-2.6.6-29.el6.x86_64 > (which doesn't have the hash randomization). > > and the build.log e.g. on x86_64 has this: > checking Python hash randomization support... no > > So this scratch build only tests the compat against older pythons lacking hash > randomization. Good catch. I just added python-2.7.3-1.fc17 as a buildroot override, and will re-build mod_wsgi against it once the buildroot gets regenerated.
F17 scratch build with hash randomization enabled: http://koji.fedoraproject.org/koji/taskinfo?taskID=398971
(In reply to comment #8) > F17 scratch build with hash randomization enabled: > http://koji.fedoraproject.org/koji/taskinfo?taskID=398971 Are you sure with that taskID? Gives me a createrepo-report. Luke, Dave, I really appreciate your work here, thanks! I'd say, go ahead! Reads like we definitely want have this feature, and we probably don't have an alternative. I'd like to try a scratch-build on monday and give feedback.
To simplify, AP_INIT_RAW_ARGS should be AP_INIT_FLAG so httpd does the off/on arg parsing for you, otherwise don't see any problems with this, would be nice to get upstream sign-off too.
Created attachment 577865 [details] A patch that adds a WSGIPythonHashSeed configuration option to mod_wsgi I just rewrote the patch, to address all of upstream's concerns. https://groups.google.com/d/msg/modwsgi/TFJYMJ30Q7w/I4C8JhUv8ScJ
SRPM with patch: http://lmacken.fedorapeople.org/rpms/mod_wsgi-3.3-3.fc18.src.rpm
Created attachment 577868 [details] A patch that adds a WSGIPythonHashSeed configuration option to mod_wsgi An updated patch that removes the PYTHONHASHSEED from the environment after the interpreter is initialized.
Thanks for talking to upstream! Fine with me if you want to push this to f17/f18.
mod_wsgi-3.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mod_wsgi-3.4-1.fc18
Package mod_wsgi-3.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mod_wsgi-3.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16222/mod_wsgi-3.4-1.fc18 then log in and leave karma (feedback).
mod_wsgi-3.4-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mod_wsgi-3.4-2.fc18
mod_wsgi-3.4-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mod_wsgi-3.4-4.fc18
mod_wsgi-3.4-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.