Reported by SecurityFocus: http://www.securityfocus.com/bid/11557/ Each version is vulnerable. Reproducible: Always Steps to Reproduce: 1. 2. 3.
php-bugs please verify and provide a patched ebuild if needed.
yup, it's a problem for anybody with USE='curl'. Here is the PHP tracking bug: http://bugs.php.net/bug.php?id=30609 No patch from upstream yet.
PHP Bug has been closed as WONTFIX : "you need to configure/install curl not to allow access to the local filesystem. It has a nice configure option for that when you are installing it." Not sure what we can do to solve this.
Inform about it when installing php?
php-bugs please advise.
One thing that could be done is php could be patched to check for "file://" and if so throw an error. This would be a simple 2-5 line patch if anyone thinks its worthwile.
Blocking file:// entirely is not an acceptable solution. I've seen a lot of code that uses file://, in a number of main-stream webapps. Given that open_basedir isn't infalliable anyway, I'm inclined to just acknowledge that it is a possible threat, but no more than many other potential security problems that cannot be fixed by software. If you wanted a programmic solutio, basically somebody needs to write a code that does parsing of the path in curl calls, and checks that they are under the open_basedir only if it is set. As I noted, open_basedir doesn't always work anyway, so the gain is very minimal.
OK so I propose that a warning is added (to ebuild or openbasedir conf option) when php is compiled with USE=curl that warns user that open_basedir can easily be bypassed in that case... Would that be acceptable ?
fine by me if that satisfies your definition of security.
Robin if you have no better proposal please provide a fixed ebuild.
Is the response from upstream that they aren't planning to fix this issue? If so, then I'd say Koon's suggestion is the best we can hope for. (unless anyone wants to suggest pulling php from the tree...) Even if they do plan to patch it, but not for a while, I think Koon's suggestion is a valid one. Our job is primarily to inform our users about security vulnerabilities. Patching is also important, but it comes after informing.
kurt: yup upstream is calling it not their problem, basically their route is to pass a configure-time option to curl to limit it to working on only a specific part of your local filesystem (which makes it useless for anything else). Proposal patch: Index: php5-sapi.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/php5-sapi.eclass,v retrieving revision 1.33 diff -u -3 -p -w -b -B -r1.33 php5-sapi.eclass --- php5-sapi.eclass 28 Nov 2004 22:51:03 -0000 1.33 +++ php5-sapi.eclass 8 Dec 2004 22:06:38 -0000 @@ -500,5 +500,9 @@ php5-sapi_pkg_postinst() { ewarn "If you have additional third party PHP extensions (such as" ewarn "dev-php/turck-mmcache) you may need to recompile them now." + + if use curl; + ewarn "Please be aware that CURL can allow the bypass of open_basedir restrictions." + fi } and a very similar one for PHP4.
Robin this is fine, please commit.
In cvs now.
Thx Robin.
This is now fixed upstream in 4.3.11 and 5.0.4 - see http://bugs.php.net/bug.php?id=30609 Patch: http://www.php.net/~jani/patches/bug30609.patch Advisory: http://secunia.com/advisories/13023/ This bug should probably be reopened. ;-)
The 4.3.11 security enhancements are treated in bug 87517, so we'll leave this one closed.
