# [Fwd: [PHP-NOTES] note 46955 added to function.curl-init] - Thread: https://externals.io/message/13584 - Original archive: https://news-web.php.net/php.internals/13584 - Started by Sean Coates on 2004-10-28T16:07:50+00:00 - Messages: 20 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #13584 — Sean Coates — 2004-10-28T16:07:50+00:00 URL: https://externals.io/message/13584#13584 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) == 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 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/) --- ## #13586 — Peter Brodersen — 2004-10-29T01:34:12+00:00 URL: https://externals.io/message/13584#13586 · In reply to: #13584 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 --- ## #13587 — Antony Dovgal — 2004-10-29T06:51:49+00:00 URL: https://externals.io/message/13584#13587 · In reply to: #13584 On Thu, 28 Oct 2004 12:07:50 -0400 Sean Coates 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 --- ## #13588 — Sterling Hughes — 2004-10-29T08:04:23+00:00 URL: https://externals.io/message/13584#13588 · In reply to: #13587 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 wrote: > > > […] > > you can find patches for all branches in attachment. > comments are welcome. > > -- > Wbr, > Antony Dovgal aka tony2001 > tony2001@phpclub.net || antony@dovgal.com --- ## #13589 — Antony Dovgal — 2004-10-29T08:18:44+00:00 URL: https://externals.io/message/13584#13589 · In reply to: #13587 On Fri, 29 Oct 2004 10:51:49 +0400 Antony Dovgal wrote: > On Thu, 28 Oct 2004 12:07:50 -0400 > Sean Coates wrote: > > > […] > > 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 --- ## #13590 — Antony Dovgal — 2004-10-29T08:20:28+00:00 URL: https://externals.io/message/13584#13590 · In reply to: #13588 On Fri, 29 Oct 2004 01:04:23 -0700 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. 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 --- ## #13591 — Klaus Reimer — 2004-10-29T08:43:11+00:00 URL: https://externals.io/message/13584#13591 · In reply to: #13588 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 (FidoNet: 2:240/2188.18) [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger k@ailis.de to get public key) --- ## #13592 — Derick Rethans — 2004-10-29T09:13:33+00:00 URL: https://externals.io/message/13584#13592 · In reply to: #13591 > 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 --- ## #13593 — Klaus Reimer — 2004-10-29T09:27:39+00:00 URL: https://externals.io/message/13584#13593 · In reply to: #13592 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 (FidoNet: 2:240/2188.18) [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger k@ailis.de to get public key) --- ## #13594 — Adam Maccabee Trachtenberg — 2004-10-29T15:24:00+00:00 URL: https://externals.io/message/13584#13594 · In reply to: #13591 > Sterling Hughes wrote: > > […] > > 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! --- ## #13595 — Peter Brodersen — 2004-10-29T15:58:06+00:00 URL: https://externals.io/message/13584#13595 · In reply to: #13592 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 --- ## #13596 — Curt Zirzow — 2004-10-29T16:26:08+00:00 URL: https://externals.io/message/13584#13596 · In reply to: #13590 * Thus wrote Antony Dovgal: > On Fri, 29 Oct 2004 01:04:23 -0700 > Sterling Hughes wrote: > > > […] > > 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! --- ## #13597 — Derick Rethans — 2004-10-29T16:55:06+00:00 URL: https://externals.io/message/13584#13597 · In reply to: #13594 > > > > […] > > 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 --- ## #13598 — Paul G — 2004-10-29T18:38:23+00:00 URL: https://externals.io/message/13584#13598 · In reply to: #13597 ----- Original Message ----- From: "Derick Rethans" To: "Adam Maccabee Trachtenberg" Cc: "Klaus Reimer" ; Sent: Friday, October 29, 2004 12:55 PM Subject: Re: [PHP-DEV] `curl_init()` is bypassing safe_mode & open_basedir restrictions > > > > […] packages? > > […] So > > […] and > > […] 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 --- ## #13607 — Adam Maccabee Trachtenberg — 2004-10-29T22:02:57+00:00 URL: https://externals.io/message/13584#13607 · In reply to: #13598 > 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! --- ## #13609 — Derick Rethans — 2004-10-29T23:03:21+00:00 URL: https://externals.io/message/13584#13609 · In reply to: #13596 > * Thus wrote Antony Dovgal: > > […] > > 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 --- ## #13631 — Antony Dovgal — 2004-10-30T11:51:12+00:00 URL: https://externals.io/message/13584#13631 · In reply to: #13596 On Fri, 29 Oct 2004 16:26:08 +0000 Curt Zirzow wrote: > * Thus wrote Antony Dovgal: > > […] > > 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 --- ## #13645 — Sterling Hughes — 2004-10-31T18:46:28+00:00 URL: https://externals.io/message/13584#13645 · In reply to: #13631 I still consider adding such things wrong.... -sterling > On Fri, 29 Oct 2004 16:26:08 +0000 > > > Curt Zirzow wrote: > > > […] > > 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 --- ## #13648 — Adam Greenfield — 2004-10-31T21:51:38+00:00 URL: https://externals.io/message/13584#13648 · In reply to: #13647 > On Sun, 31 Oct 2004 10:46:28 -0800 > Sterling Hughes wrote: > > > […] > > 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 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