| « Designing Databases: Picking The Right Data Types | PHP Interview Questions And Answers » |
Last week, I received an email from someone who told me how the Suhosin patch had created problems for their team, and suggested that I write about it here. I thought this was a great idea, for a number of reasons. Particularly, Suhosin is one of those PHP patches that alters the way PHP operates in a fundamental fashion, yet also is installed by default in many places (for example, Ubuntu compiles this patch in by default on their installation).
For starters, what is Suhosin? Suhosin is a PHP patch that “hardens” PHP’s security features. The makers of Suhosin describe it in this way:
Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.
So how does Suhosin affect you? Suhosin can affect you because it fundamentally alters the way PHP operates. Here are some of the features and “gotchas” that you should watch out for:
Allows the disabling of eval()
If your application uses eval() for any reason, and you deploy it to a remote server hosted by someone else, there’s a chance that they may have disabled eval() which would break your application.
I have no intention of defending eval(); I don’t use it, and I’m not going to make statements on whether or not you should. However, if you have a legitimate use, you must be careful to make sure that eval() is not disabled.
Disallowing of Remote URL Inclusion
While this is generally a poor programming practice to begin with, Suhosin disables your ability to include remote URLs. For exmaple:
horribly dangerous programming practice in the first place (you should use file_get_contents() instead), it might generate problems for your application if you are unaware that Suhosin is installed.
Changes scripts ability to modify the memory_limit
Occasionally, on the fly, I’ve changed the memory limit on one script (a cron job, for example) in order to prevent the script from failing. This value can be set throughout PHP; however, Suhosin changes this behavior and does not allow you to change the memory limit on the fly. This can create problems if you expect/need the memory limit to be alterable.
Allows limits on length of REQUEST arrays
If you have a particularly long form, you may run into this problem: Suhosin allows you to limit the length of the REQUEST array, thus limiting how long your form is. While you may never run into this, you should be aware of the possibility that Suhosin might be responsible for this.
Super-long arrays can create problems in PHP, and attackers might attempt to add millions of form fields with the hopes of generating an error or somehow affecting your application. While this protection can be good, you should be aware of its ability to adjust and affect your application as well.
So is Suhosin bad?
Absolutely not. Suhosin does a number of good things, and helps prevent against a number of possible attacks and vulnerabilities in PHP. That being said, Suhosin is not a replacement for good coding practices. Its installation on major servers is largely due to the fact that server owners wish to configure components of PHP that are not otherwise configurable due to the way PHP is configured. It is therefore their right to install this patch and configure it any way they like.
Suhosin is by no means a requirement for PHP development. You can, and should, learn the PHP best practices so that patches like Suhosin are merely an aid, not a crutch. Still, because Suhosin is installed by default as a part of many PHP installations (this server uses Suhosin), you should be aware of it’s ability to act as a little bit of an “invisible hand” throughout the PHP world, guiding your security choices before you even have the chance to make them.
How do I make sure my application is compatible with Suhosin if I’m going to use it?
Suhosin includes a compatability mode called suhosin.simulation. This will log, but not block, the execution of things that Suhosin finds objectionable. You can use this mode to determine whether or not Suhosin works for your application and what restrictions will affect you.
Chances are good that if you’re running up against Suhosin problems, you should seriously reconsider what it is that you’re doing and see whether or not it’s worthwhile or a good programming practice. Suhosin isn’t perfect, but you should take its warnings seriously.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 11/18/2009 at 1:00 am
Nick Pack (@nickpack) wrote at 11/18/2009 1:46 am:
Might also be worth mentioning the session data encryption on this as well Brandon, simplest case of this not working is flash uploaders – you will run into issues with encrypted sessions and flash doing http requests (This is a common problem in magento for example)
Another thing for a possible mention, is that with hosts than run apache with mod_php you can (if overrides are allowed) set suhosin flags to override config settings in the same way that you can set core php options
Stefan Esser wrote at 11/18/2009 2:10 am:
Hello Brandon,
sorry but your blog posting about Suhosin is simply “wrong”.
First of all Suhosin is a 2 part system. That means there is a patch and an extension that can be used alone or together. The difference is that the patch implements low level security while the extension implements high level security.
That said in most cases only the suhosin patch is activated by default which adds protections around PHP internal functions. Aside from patches to how realpath works (which is no longer needed and done for PHP >= 5.3.0) there is no influence on PHP scripts. If PHP scripts break with only Suhosin patch applied this means they ultimatively suck, because they trigger memory corruption problems within PHP. If these scripts work with standard PHP and do not crash then you are simply lucky. The right way here would be to track down the memory corruption inside PHP and fix it.
So all the features you discuss are within the Suhosin extension that is NOT installed by default in many places.
a) disable eval – well honestly I have never seen a system in the wild that makes use of this features and the documentation clearly states that enabling this feature will break apps
b) every application relying on remote URL inclusion is insecure. Beside the fact that remote URL inclusion are not allowed in PHP 5.2.0 and greater anyway. So if you want your application to work with new PHP you have to fix that anyway.
c) memory_limit – compatible applications always had to take care of activated safe_mode which also disallows changing the memory_limit. Beside the fact that suhosin does NOT disallow changing the memory_limit. It allows the admin to set a second HARD memory_limit that he does not want to see violated. So you can change memory_limit as long you do not try to overrun the hard memory_limit
d) limit on request – yes indeed this feature causes problems with many things. But that is just because admins just install suhosin and believe they do not need to configure it. Security out of the box. But this is like installing a fresh Fedora installation and then crying because you cannot access the webserver because the firewall blocks all incoming ports by default.
Andy Thompson (@andytson) wrote at 11/18/2009 2:55 am:
Suhosin is simply set by default to be strict on a few settings, you can easily turn off these options if they don’t suit your needs.
In most, if not all, cases where Suhosin acts against a request, it will display an error in the error log, allowing you to see what its doing, so you can decide whether to turn off a feature.
You’ve got to consider, however, the security of code you don’t manage as well. WordPress seems to have people finding new ways to upload remote code and inject every month, so one of the things I’ve done is specifically for that WordPress vhost, turn on:
suhosin.executor.include.allow_writable_files
and now if someone somehow manages to upload a file, it can’t be included.
James (@jwm0z) wrote at 11/18/2009 9:47 am:
@stefan, just so you know, r.e. your point a), Vbulletin EXTENSIVELY uses eval()’s (as i’ve unfortunately had to learn over the past month or so).
Pablo Viquez (@pabloviquez) wrote at 11/18/2009 10:20 am:
Like Rasmus said…, “If eval() is the answer, youre almost certainly asking the wrong question.”
Chuck Burgess (@ashnazg) wrote at 11/19/2009 10:51 am:
The key point here seems to me to be “when *you* don’t control your PHP installation, be _aware_ of _potential_ gotchas that _might_ result from Suhosin protections that get triggered by your coding practices”.
With one or both parts of Suhosin beginning to be included by default in webserver installations, having the “symptoms” highlighted to the unaware developer seems to me to have merit.
Alexandr wrote at 11/29/2009 5:23 pm:
Thank you Brandon, with Debian I always have Suhosin, but never seen its configuration options, because my apps just work as I expected.
People, thanks for your comments – take me different view points. Specially for Stefan Esser – really helpful post, every point have explanations.
| « Designing Databases: Picking The Right Data Types | PHP Interview Questions And Answers » |