-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.

| improve this question | | | | |
  • 2
    Huh? The importance here is not of using open_basedir but of not running insecure code and of properly isolating PHP. – Michael Hampton Mar 26 '13 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 '13 at 19:23
  • How many more "hacking incidents" will it take? – Michael Hampton Mar 26 '13 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 '13 at 19:35
  • 3
    Update your resume and run like hell. – Michael Hampton Mar 26 '13 at 19:42
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.

| improve this answer | | | | |
  • 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 '13 at 20:26
  • I would use something nonstandard so others do not accidentally put binaries in it, e.g., /usr/local/php_allowed_bin/ – Mark Wagner Mar 26 '13 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.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.