Webservers Writing To Disc
It’s been a while since I posted about the Wordpress changes I’ve made, and I’m still not planning on releasing an open source package of it, but I thought I should at least talk about one of the changes I made because they really are worth talking about. One of the biggest flaws in how Wordpress is architected is that it expects to be able to write onto the file system. More dangerous than that, is that it expects to be able to write to parts of the drive within the server root AND files that are actually interpreted by the system (.htaccess and .php). Ouch! One vuln and you can kiss your server goodbye. But it’s worse than that.
On multi-user systems you have to worry about not just outsiders, but others on the same system potentially hijacking your system. Let’s say there are two www writable user directories, one with Wordpress, and the other with nothing other than PHP or CGI access. Suddenly, because the www user can access the place on disc the attacker (the other user on the file system) can now take over the other person’s install by writing a CGI or PHP function. The attacker runs it from their browser, which accesses the site, which runs as the www user, which has access to write into the other person’s .htaccess file or php. From there, they now have complete access to hijack the site.
That’s pretty bad, but there is a very simple solution. Once configuration is complete, remove all www access from being able to write to those files. Pretty simple, huh? That makes changing the configuration a bit of a pain, but who cares? How often do you configure your site? Once a year? Compared to the problems it can cause to allow it to be configurable, it’s worth it. Really, there is a better way so solve the multi-user system problem though - and that would be to use an apache module that allowed it to run as multiple users (one per user). It would have to start as root, of course, but it could spawn as many processes as required to get the user seperation needed. That way one user couldn’t access another user’s webserver directory period, unless the user foolishly did something like chmoding a file 666 or 777 instead of 600 or 700 or something.
October 8th, 2007 at 10:25 pm
Two questions:
Is there any way to mitigate the risk where there is a good reason for letting the server write to the file system: for example for caching?
Using FastCGI on a multi user system, each process does run as a user. Is there then any way to stop vulnerabilities in the application from allowing the making of changes to the application?
I once had two users, one who owned application files, the other who owned data files. I cannot do this kind of thing on shared hosting though!
October 9th, 2007 at 1:39 pm
You can do this for CGI’s with suExec. http://httpd.apache.org/docs/2.2/suexec.html
If you want to achieve it otherwise, you can set up multiple servers on multiple ports fronted by a single proxy server with mod_rewrite.
If you’re running fastcgi, you can specify different user/group combinations for the multiple fastcgi handlers.
Are you looking to do something different than this?
October 9th, 2007 at 9:03 pm
@Graeme - to me that seems more of the job of a webservice or a database rather than a back end file read. Or am I missing something?
@Andy - suExec works only if you have it installed - same with running many different webservers. I was talking about a major fundamental shift in the way all webservers work. Slightly different. Yes, you can hack it into the webserver using compiled modules, but then no one will do it because it’s non-standard, and honestly, most people aren’t tech savvy enough to know to do it in the first place (the same people who use the open sourced applications I might add). I’d rather have a hardened web server to begin with (something I’ve yet to see built and desperately needed).
October 11th, 2007 at 1:33 pm
writing to .htaccess is mostly requird in CMS systems for the ease of using clean/friendly URLs (static URLs). imagine cms with plugins functionality. each plugin can have their own way of addressing URLs and therefore requires write access to .htaccess.
writing .php files is silly, but then you can always enable SAFE MODE in PHP and PHP file of one user (UID) won’t be accessible to other users (different UIDs).
October 11th, 2007 at 4:24 pm
Summary: Apache module: suPHP - execute PHP scripts with the permissions of their owners
http://www.suphp.org/
suPHP is a tool for executing PHP scripts with the permissions of
their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.
Many software dont work with Safe_Mode but IMHO globally safemode should be On and if its needed You can turn off safemode via “php_admin_value safe_mode off” by virtual hosts.
October 15th, 2007 at 10:04 am
I think RSnake is on the right tracks when mentioning what should be the default starting point; a hardened server.
The issues mentioned are the ground on which any decent MAC scheme deploys, be it SELinux, RSBAC, Grsecurity or even AppArmor. Perhaps, even, the ol’ good [sic…] Linux capabilities and AICs could offer something here.
I am of course assuming that a person runs a decent operating system and is capable of properly administrating it, to begin with. Because more than often these assumptions fail when we move to the real-world, we have a whole software industry providing such partial solutions such as suPHP or server-level “firewalls”.
October 17th, 2007 at 9:02 am
So this is totally correct. The problem is that except for Apache, pretty much every piece of Web software out there wants to write into its own directories. It’s immensely frustrating. In my opinion, all Web software should be architected so that highly transitive files (logs, temp files), the binaries, and mildly volatile files (config) can be segregated and placed on different types of storage. A Java app server could run off a CDROM and be much more compromise proof using this model. You could mount the config disk read-only and remount it for production moves.
Trying to put this off on system admins to run some super-hardened UNIX with all kinds of addons is sadly misguided and will result in everyone’s site other than the several “3l33ts” out there to be compromisable. The applications/services need to be architected securely in the first place.
VMs are a potential partial solution here; if the app is sufficiently compartmentalized (all data held in a back end DB, etc) then you can set up a VM with the right config and just refresh it regularly from a copy.
October 18th, 2007 at 12:50 am
@Ernest:
I was trying to emphasize that these “super-hardened UNIX” systems [sic] are not (yet) a real solution in the real world. Naturally you are right: potentially insecure coding practices are the very essence that these systems and “addons” are trying to countermeasure.
It is an admirable opinion that services (powered by PHP, say) would be architectured securely in the first place. Indeed, admirable goal for the whole internet.
At the very same time you are for some reason downplaying these schemes to be something of “3l33t”. A reminder: if you take a brief look to the big Linux distributions out there, every single one has choosen to deploy one of these. Yes: this includes even the recent version of Ubuntu. If you are doing hosting on Windows, surely, homegrown solutions such as putting binaries in CDROM might be the only solution. And if you think there is something “elite” in administrating, say, the SELinux framework — slowly starting to be a mainstream security solution –, I fail to see how virtual machine hosting would be somehow less demanding to setup.
Please take this as a footnote; there was no intention to be a troll.
October 22nd, 2007 at 7:13 am
You mentioned being able to run Apache as any user (dependent on what site is requested), there is a way to do that:
http://mpm-itk.sesse.net/
But yes, until this mod kicks in the process is owned by Apache, this could make a flaw in mod_ssl totally lethal.
October 22nd, 2007 at 7:21 am
Sorry, I mean owned by root, not Apache.