One of my projects for the “holidays” is moving one of my servers from Gentoo to Ubuntu. During planning for this, I noticed that the Ubuntu version of PHP5 includes Suhosin. That’s a problem.
The problem with Suhosin is that it’s designed to stop sloppy applications from doing bad things. I’m sure it does a reasonable job of that, but in the process it can interfere with good applications (see examples for Joomla). Since I’m in the business of writing good applications, Suhosin is a bad idea. Worse yet, it can provide a false sense of security, since it can’t deal with anything except typical PHP errors. As far as I’m concerned, this class of “security blanket” provides false comfort and is no replacement for auditing and testing.
So there’s the rationale. Here is the method:
- Create a working directory:
mkdir packages
- Enter the directory:
cd packages
- If you haven’t built a Debian package before get development scripts:
sudo apt-get install devscripts
- If this system hasn’t been used for development, you need a minimal tool set:
sudo apt-get install gcc debhelper fakeroot
- Get the PHP5 source (do not use sudo on this one):
apt-get source php5
- Enter the PHP5 directory (versions may vary, at the moment it is php5-5.2.4):
cd php5-5.x.y
- Ensure an unmodified PHP will build. This might take some time as it fetches various dependencies.
sudo apt-get build-dep php5
- Remove the patch file:
rm debian/patches/suhosin.patch
- Remove the reference to the patch (delete the line that contains suhosin.patch with Ctrl-K, then Ctrl-O to save and Ctrl-X to exit):
nano debian/patches/series
- Increment the version number. This can be problematic. Your version number is likely to be different from the one listed here, and I found some reports that having the string “suhosin” in the version can confuse some applications into thinking Suhosin is installed. I simply appended “.1~custom” to the current package version:
debchange -v 5.2.4-2ubuntu5.4.1~custom
- The version bump will pop the nano text editor. Move to the end of the auto-selected line, enter a comment like “Removed Suhosin.” then press Ctrl-O to save, Ctrl-X to exit.
- Finally build the package (note only one “b” in “deb build”):
debuild
- Take a break, the build will take a while. Ignore the hundreds of warnings that scroll past.
- You should have new packages:
ls ../php5*
- Quick and dirty install (might break stuff):
sudo dpkg -i ../*.deb
[I will look for a better way and update this if I find it.]
Credits: I found this process in the Ubuntu forums. This version accounts for a few problems I encountered when following the original. I am anything but a build expert, and any requests for assistance are likely to be ignored or met with “beats me”. Your mileage may vary.
I’ve submited a bug report on this.
Probably do no good but you never know.
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/315507
i got this error
gpg: skipped “server-admin“: secret key not available
gpg: [stdin]: clearsign failed: secret key not available
debsign: gpg error occurred! Aborting….
debuild fatal error at line 1174:
running debsign failed
I got this error, too
gpg: keyring `/home/webnet/.gnupg/secring.gpg’ created
gpg: skipped “webnet “: secret key not available
gpg: [stdin]: clearsign failed: secret key not available
debsign: gpg error occurred! Aborting….
debuild: fatal error at line 1250:
running debsign failed
If you look in the deb folder the files will be have made even with the debsign error.
If you’ve followed this guide the files will be up one directory.
Thank you for this detailed guide. How frustrating it is to see that the Ubuntu maintainers don’t understand that Suhosin breaks tons of shit.
i am compiling that right now and i hope it will fix problems with apc_fetch and uploading file progress..
will comment when i am done.. iit makes long time 🙂
This has been driving me nuts. I was already in the process of the re-compile sans suhosin looking for an already compile .deb. I’m doing this for 9.04/64, but the problem is the typical 52 packages with dependencies, and then Ubuntu upgrades and, ….
I think this is a great tip. In fact, I’m using it now because I’m setting up an intentionally insecure site for demonstration purposes.
While Suhosin certainly can ‘break shit’, I’d argue that it’s better to learn to work around it than to remove it all together. But that’s me, a security guy. Using PHP is playing with a loaded weapon if you are not very very careful. If you (‘you’ not being the author but the reader) do remove Suhosin, please, for the love of god, do some pen testing on your site and make sure you look for flaws. Otherwise you’ll be owned very quickly when that trouble could have been avoided.
W3AF would serve as a great ‘sanity’ check for developers who go it alone (or anyone else).
All the best.
Indeed, there are now reasonable instructions available that make it possible to disable the more odious features of Suhosin and keep nice things like buffer overflow checking.
I recommend that people use this approach rather than remove the package altogether.
Still, my objection to these sorts of tools is not only the false positives, but the false sense of security they generate. Many a site owner thinks they’re 100% protected because they have some array of tools and filters configured. Armed with this illusion, they feel comfortable in ignoring vulnerability reports and critical upgrades, and then are upset when their sites get hacked.
Can I use “suhosin.emulation = On” parameter for turn off suhosin?
http://www.hardened-php.net/suhosin/configuration.html#suhosin.simulation
You could also try the command:
aptitude purge php5-suhosin
Can you tell me, how to compile php5 without suhosin on debian squeeze?