Atomicorp

I have a customer who wants safe mode off, popen enabled and url_fopen enabled.
This is for some sort of CMS.

I noticed that Magento also requires similar things to be enabled.

And I've just encountered something I wanted to investigate - OwnCloud - which requires safe mode off and popen enabled.

The php running as the FTP user in FastCGI mode, just how dangerous is this in real as opposed to theoretical terms, especially since open_basedir is still in effect and most other "dangerous" functions are disabled?

Thanks for the question, so heres our take on these:

"safe mode off"

Moderate to low risk, the key value people got from this was that if the PHP script wasnt owned by the user Apache was running as, it wouldnt run. Which was (and is) designed to prevent someone else from putting PHP scripts in your world writable html directory, like another user on the box.

popen

https://www.atomicorp.com/wiki/index.php/Vuln_php_popen

Basically, think of this as the same as "system", "shell_exec" and "exec". It means if the popen functions are poorly written, the bad guys to run any command they want on your system. Equally, if they upload a piece of PHP malware that uses those functions it will work. The later is just as important as the former, because there is a lot of PHP malware outthere that cant do anything unless you allow one of these kinds of functions to work.

url_fopen

https://www.atomicorp.com/wiki/index.ph ... _url_fopen

Really really bad. This means a URL is treated as a file, from any server on the internet. That means you can tell PHP that the PHP file it wants to load is running on a box the bad guy controls. I cant tell you how many PHP apps have had a vulnerability that was solely preventable because of this function.

With that said, ASL will stop RFI attacks, so if you have to do this you are losing an important layer of defense in depth but you arent completely exposed.

and most other "dangerous" functions are disabled?

The problem is popen is the equivalent of things like system, exec, etc. And the bad guys write their payloads to try all the equivalent functions, so if you have one enabled, its basically like having them all enabled.

If you must work with remote files: use the PHP cURL library in stead of allow_url_fopen.

Wonderful info. Thanks guys!

and suhosin could be helpful here, that would allow you to create whitelists of URL's that php functions can access, among many of its other features.

Just remember to benchmark your suhosin performance, it like anything else thats doing work can cause slowdowns in some cases:

http://www.hardened-php.net/suhosin/benchmark.html

We use suhosin on all our systems as a matter of course. Specifically to blacklist functions on a per-domain basis. I wasn't aware that it could whitelist URLs for fopen as well. Most interesting indeed.

We've not noticed any performance issues with it, but I've never benchmarked it.