Is this legitimate?
I took a (very) quick look at bugs, and didn't see it.
(deleted the note)
S
-------- Original Message --------
Subject: [PHP-NOTES] note 46955 added to function.curl-init
Date: Thu, 28 Oct 2004 09:03:55 -0700
From: mars012.mail.ru@osu1.php.net (a)
To: php-notes@lists.php.net
from http://www.packetstormsecurity.org/0410-advisories/php4curl.txt
====================================================
Subject: PHP4 cURL functions bypass open_basedir
Author: frame at kernelpanik.org
Product: PHP4 compile with cURL (not tested in PHP5)
Vendor: PHP/Zend
Vendor URL: www.php.net
Tipe: Local
Risk: Low/Medium
PHP cURL functions bypass open_basedir
protection, so users can navigate through
filesystem.
For example, setting "open_basedir" in php.ini to
"/var/www/html" anybody can retrieve "/etc/parla"
using cURL functions.
== Proof of concept (curl.php)
<?php
$ch = curl_init("file:///etc/parla");
$file=curl_exec($ch);
echo $file
?>
== Demo
$ cat /etc/parla
don't read please!
$ links -dump http://localhost/curltest/curl.php
don't read please!
== Release Timeline
No release timeline.
--
FraMe frame@kernelpanik.org
http://www.kernelpanik.org
Manual Page -- http://www.php.net/manual/en/function.curl-init.php
Edit -- http://master.php.net/manage/user-notes.php?action=edit+46955
Delete --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes
Reason: bad code --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes&reason=bad+code
Reason: spam --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes&reason=spam
Reason: useless example --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes&reason=useless+example
Reason: contains commercial links --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes&reason=contains+commercial+links
Reason: useless note --
http://master.php.net/manage/user-notes.php?action=delete+46955&report=yes&reason=useless+note
Reject --
http://master.php.net/manage/user-notes.php?action=reject+46955&report=yes
Search -- http://master.php.net/manage/user-notes.php
--
PHP Notes Mailing List (http://www.php.net/)
On Thu, 28 Oct 2004 12:07:50 -0400, in php.internals sean@caedmon.net
(Sean Coates) wrote:
Is this legitimate?
I took a (very) quick look at bugs, and didn't see it.
It bypasses safe_mode as well (4.3.9)
interface.c has the following note, though:
/* the following options deal with files, therefor
safe_mode & open_basedir checks
* are required.
*/
.. but it only seems to regard storage of cookiefile and
ssl-certificate.
--
- Peter Brodersen
On Thu, 28 Oct 2004 12:07:50 -0400
Sean Coates sean@caedmon.net wrote:
Is this legitimate?
I took a (very) quick look at bugs, and didn't see it.
you can find patches for all branches in attachment.
comments are welcome.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
On Thu, 28 Oct 2004 12:07:50 -0400
Sean Coates sean@caedmon.net wrote:Is this legitimate?
I took a (very) quick look at bugs, and didn't see it.you can find patches for all branches in attachment.
comments are welcome.--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes sterling.hughes@gmail.com wrote:
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
- Thus wrote Antony Dovgal:
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes sterling.hughes@gmail.com wrote:no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?
One thing I noticed in some testing was the host part in the
file:// url has no meaning so:
curl_init('file://whateveryouwant/etc/group');
Works fine.
Curt
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
- Thus wrote Antony Dovgal:
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes sterling.hughes@gmail.com wrote:no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?One thing I noticed in some testing was the host part in the
file:// url has no meaning so:curl_init('file://whateveryouwant/etc/group');
Works fine.
That's exactly what my point in an earlier mail meant:
"It's almost certain that one can never put all the necessary checks in
the extension anyway."
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Fri, 29 Oct 2004 16:26:08 +0000
Curt Zirzow curt@php.net wrote:
- Thus wrote Antony Dovgal:
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes sterling.hughes@gmail.com wrote:no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?One thing I noticed in some testing was the host part in the
file:// url has no meaning so:curl_init('file://whateveryouwant/etc/group');
yup, I see it now.
I can change the patch to check this too.
Currently I'm waiting for Sterling's response.
It's senseless to add any additional checks if he still considers
that adding such things is wrong.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
I still consider adding such things wrong....
-sterling
On Fri, 29 Oct 2004 16:26:08 +0000
Curt Zirzow curt@php.net wrote:
- Thus wrote Antony Dovgal:
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes sterling.hughes@gmail.com wrote:no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.agree, curl doesn't need to respect safemode, but PHP does.
we're talking about PHP's extension, right ?One thing I noticed in some testing was the host part in the
file:// url has no meaning so:curl_init('file://whateveryouwant/etc/group');
yup, I see it now.
I can change the patch to check this too.Currently I'm waiting for Sterling's response.
It's senseless to add any additional checks if he still considers
that adding such things is wrong.--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
On Sun, 31 Oct 2004 10:46:28 -0800
Sterling Hughes sterling.hughes@gmail.com wrote:
I still consider adding such things wrong....
Sterling, I still think that you can be right, but I'd
like to hear some arguments.
"This is wrong" or "this is silly" aren't too informative.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
On Sun, 31 Oct 2004 10:46:28 -0800
Sterling Hughes sterling.hughes@gmail.com wrote:I still consider adding such things wrong....
Sterling, I still think that you can be right, but I'd
like to hear some arguments.
"This is wrong" or "this is silly" aren't too informative.
I think the best argument came from Derick
Privilege seperation should be a function of a
webserver, not of a scripting language and therefore we shall not put
hacks in extensions because libraries do not adhere to safe mode. It's
almost certain that one can never put all the necessary checks in the
extension anyway.
Speaking as an administrator who would be particularly affected by
this situation (I work at a web hosting company that does a fair
amount of shared web hosting) I could not agree more. Safemode should
not attempt to modify the actions of the underlying libraries.
Setting up a solid shared hosting platform takes a lot more than just
one PHP option, and if you don't want this functionality in curl on
your system, you should remove it from curl.
However that is just my 2 cents.
--
Adam C. Greenfield
<adam.greenfield@gmail.com
Sterling Hughes wrote:
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
What about people who use precompiled packages like the Debian packages?
They don't have a "special" Curl for PHP. The curl debian package will
never "disable" file-support just because it breaks a feature of PHP. So
Debian users can't use safemode then if they need the curl extension and
if they don't want (or don't know how) to compile the stuff.
And what about PHP installations on Windows (if there is a safe-mode and
a curl extension, don't know). Especially Windows Users are not used to
"compile" PHP. They are just downloading and installing DLLs.
In my opinion it would make sense to check the file://-URL inside the
PHP extension before it goes to the curl library if safe mode is
enabled. There must already be a check for this for PHP's fopen
function, maybe this check can be re-used for this?
Safe-mode is a feature of PHP so PHP should make sure that this feature
is working with all functions included in PHP if it's possible to secure
the function (otherwise the user must disable it). And there is already
a patch to do it, so it seems to be possible to secure the curl functions.
--
Bye, K http://www.ailis.de/~k/ (FidoNet: 2:240/2188.18)
[A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391]
(Finger k@ailis.de to get public key)
Safe-mode is a feature of PHP so PHP should make sure that this feature
is working with all functions included in PHP if it's possible to secure
the function (otherwise the user must disable it). And there is already
a patch to do it, so it seems to be possible to secure the curl functions.
Myth: Safe mode makes a PHP installation safe.
Wrong! It might make it a bit safer, but there is always a possibility
to work around it. Privilege seperation should be a function of a
webserver, not of a scripting language and therefore we shall not put
hacks in extensions because libraries do not adhere to safe mode. It's
almost certain that one can never put all the necessary checks in the
extension anyway.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
Myth: Safe mode makes a PHP installation safe.
I never said this.
webserver, not of a scripting language and therefore we shall not put
hacks in extensions because libraries do not adhere to safe mode.
If there IS a possibility to make safe-mode a little bit more secure why
don't do it? The fopen command of the libc doesn't check for safe-mode,
so PHP is doing it. The curl library does not check for safe-mode but in
this case you don't want PHP to do the check? Extension or not, the PHP
curl functions are part of PHP, it's not an unsupported PECL extension.
It's almost certain that one can never put all the necessary
checks in the extension anyway.
That's absolutely clear. That's why PHP has the ability to disable
functions which can't be secured for safe-mode. But if this argument
leads to sporadic securing of PHP functions (like "Why should I secure
this function even if it's possible? safe-mode can't be secure
anyway...") then safe-mode seems to make no sense at all.
--
Bye, K http://www.ailis.de/~k/ (FidoNet: 2:240/2188.18)
[A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391]
(Finger k@ailis.de to get public key)
On Fri, 29 Oct 2004 11:13:33 +0200 (CEST), in php.internals
derick@php.net (Derick Rethans) wrote:
Myth: Safe mode makes a PHP installation safe.
Wrong! It might make it a bit safer, but there is always a possibility
to work around it.
On the other hand, I think it's a pity not to freshen up code, just
because someone turns the argument around: "There is always a
possibility to work around it".
I think that's the case with the glob()-issue. There is some weirdness
with the way that glob() behaves, but there was a reason for adding
the safe_mode-check in the first place. There is some inconsistensy in
first adding some features with defect safe_mode-aware checks, and not
fixing these defects, because safe_mode is a hack. Otherwise, remove
safe_mode totally, once and for all.
But before safe_mode is politically decided bad and should be removed
entirely, one must respect that it is present and part of the system -
for better and for worse.
By the way, since it's a myth, you might stop repeating the myth,
since no-one else bombastically claimed that "Safe mode makes a PHP
installation safe" :)
--
- Peter Brodersen
Sterling Hughes wrote:
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.What about people who use precompiled packages like the Debian packages?
They don't have a "special" Curl for PHP. The curl debian package will
never "disable" file-support just because it breaks a feature of PHP. So
Debian users can't use safemode then if they need the curl extension and
if they don't want (or don't know how) to compile the stuff.
Safe mode is for people who are running shared servers and want to
wall off areas. If you're doing this, you should be willing and able
to configure programs if necessary. I don't mind making ISP sys admins
configure cURL with a special flag, nor do I think it's too onerous a burden.
-adam
--
adam@trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
Sterling Hughes wrote:
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.What about people who use precompiled packages like the Debian packages?
They don't have a "special" Curl for PHP. The curl debian package will
never "disable" file-support just because it breaks a feature of PHP. So
Debian users can't use safemode then if they need the curl extension and
if they don't want (or don't know how) to compile the stuff.Safe mode is for people who are running shared servers and want to
wall off areas. If you're doing this, you should be willing and able
to configure programs if necessary. I don't mind making ISP sys admins
configure cURL with a special flag, nor do I think it's too onerous a burden.
Exactly!
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
----- Original Message -----
From: "Derick Rethans" derick@php.net
To: "Adam Maccabee Trachtenberg" adam@trachtenberg.com
Cc: "Klaus Reimer" k-php-dev@ailis.de; internals@lists.php.net
Sent: Friday, October 29, 2004 12:55 PM
Subject: Re: [PHP-DEV] curl_init() is bypassing safe_mode & open_basedir
restrictions
Sterling Hughes wrote:
no.... curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.What about people who use precompiled packages like the Debian
packages?
They don't have a "special" Curl for PHP. The curl debian package will
never "disable" file-support just because it breaks a feature of PHP.
So
Debian users can't use safemode then if they need the curl extension
and
if they don't want (or don't know how) to compile the stuff.Safe mode is for people who are running shared servers and want to
wall off areas. If you're doing this, you should be willing and able
to configure programs if necessary. I don't mind making ISP sys admins
configure cURL with a special flag, nor do I think it's too onerous a
burden.Exactly!
and what happens in the (admittedly unlikely) case where something else on
the same box depends on that feature being available in libcurl? i don't see
what is wrong in restricting the functionality exposed by the php curl
extension based on safe_mode in practice (as opposed to ideally) provided
the patch is clean, straightforward and without breakage side effects.
paul
and what happens in the (admittedly unlikely) case where something else on
the same box depends on that feature being available in libcurl?
They can build two copies of cURL.
-adam
--
adam@trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
On Fri, 29 Oct 2004 10:51:49 +0400
Antony Dovgal tony2001@phpclub.net wrote:
On Thu, 28 Oct 2004 12:07:50 -0400
Sean Coates sean@caedmon.net wrote:Is this legitimate?
I took a (very) quick look at bugs, and didn't see it.you can find patches for all branches in attachment.
comments are welcome.
sorry, fixed some leaks.
now all patches should be ok.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com