-1

A hacking incident a couple of months ago taught me the importance of using open_basedir on PHP sites. But now I need to get ImageMagick to work on a Drupal site and I get an error saying it can't access /usr/bin/convert because of open_basedir. /usr/bin and everything in it is writable only by root, but there are a lot of scripts in there, and giving the site access to all of them worries me.

6
  • 2
    Huh? The importance here is not of using open_basedir but of not running insecure code and of properly isolating PHP. Mar 26, 2013 at 19:16
  • I agree with you completely but, my bosses are not going to give me time to update all the outdated code with known exploits running on our servers. This job is kind of a nightmare.
    – Kevin
    Mar 26, 2013 at 19:23
  • How many more "hacking incidents" will it take? Mar 26, 2013 at 19:25
  • Good question. My bosses don't seem to understand that server administration is a full time job and I'm also their web developer/programmer/tech support guy.
    – Kevin
    Mar 26, 2013 at 19:35
  • 3
    Update your resume and run like hell. Mar 26, 2013 at 19:42

2 Answers 2

2

No, it isn't safe to add /usr/bin to open_basedir. Once an attacker can execute arbitrary PHP code they will then be able to execute any command in /usr/bin.

To limit the attack surface area you could create a bin directory under open_basedir and make a link to convert in it. Make sure it isn't under your web root.

2
  • What if I were to create a single bin directory under /usr/local, with a symlink to convert in it? Then I could add that to the open_basedir of all the sites that needed it.
    – Kevin
    Mar 26, 2013 at 20:26
  • I would use something nonstandard so others do not accidentally put binaries in it, e.g., /usr/local/php_allowed_bin/ Mar 26, 2013 at 20:31
0

Obviously we don't know the details of the hack, but in order to exploit something which might have been prevented by setting open_basedir properly then there is a different vulnerability on your system. But that's beside the point.

There are lots of ways to solve the problem - allowing the PHP script limited access to the relevant binaries / setting up the permissions so you can allow access to the dir without exposing lots of other stuff (but unless your imagemagick is statically linked then you'll also need to open up the libs). The problem is that they rely on Byzantine permission models - which are likely to get trampled on by distro upgrades.

If it were me I'd run the conversion in a completely independent process group. How you go about that depends on whether your PHP script needs to know if the job completes successfully or not. If it doesn't need to know, then an asynchrnous message queue (rabbitMQ, SMTP linked to a procmail recipe, or just some records in a database) will process the jobs with manageable capacity. If it needs a confirmation, then run a forking daemon to exec the conversion.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .