Russell Nelson wrote:
There is no problems with the include() statement. The only thing
missing, is a blink tag in the docs ;)
If there were no problems, then why would a blink tag be needed?
He's trying to say, as I was - that the include() function works as
expected and is just fine as
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
Gareth Ardron writes:
You absolutely can't trust any input whatsoever and it must be
validated.
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells
Please troll, do you go away if I close my eyes?
--Jani
On Wed, 29 Jun 2005, Russell Nelson wrote:
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
-Original Message-
From: Russell Nelson [mailto:[EMAIL PROTECTED]
Sent: mercredi 29 juin 2005 08:09
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
Jani Taskinen [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Jani Taskinen [EMAIL PROTECTED] writes:
Please troll, do you go away if I close my
[EMAIL PROTECTED] wrote:
Jani Taskinen [EMAIL PROTECTED] 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
On Wed, 29 Jun 2005, Sebastian Mendel wrote:
[EMAIL PROTECTED] wrote:
Jani Taskinen [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
{
char badstring[3] = { '1', '0', '0' };
long not100 = atol(badstring);
}
Only intrinsicly safe if you've read the manual page to know that badstring
should have been null terminated.
On Wed, 29 Jun 2005, Sara Golemon wrote:
Nope. Some functions are intrinsically safe, e.g. C's atol, or strtol.
It's all in the design, you see.
{
char badstring[3] = { '1', '0', '0' };
long not100 = atol(badstring);
}
Only intrinsicly safe if you've read the manual page to
On 6/29/05, Russell Nelson [EMAIL PROTECTED] wrote:
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
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
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 |
Guus Leeuw jr. writes:
These programmers need to make sure that their program copes well with
incorrect or harming input.
Your argument is ridiculous. Essentially you are saying that circular
saws should not come with a guard on the blade, and that circular saw
users should invent their own
Derick Rethans writes:
On Wed, 29 Jun 2005, Sara Golemon wrote:
Only intrinsicly safe if you've read the manual page to know that
badstring should have been null terminated.
Oh, don't get me started on C's null-terminated strings!
Stop feeding the troll please.
Public requests to
Russell Nelson wrote:
Derick Rethans writes:
On Wed, 29 Jun 2005, Sara Golemon wrote:
Only intrinsicly safe if you've read the manual page to know that
badstring should have been null terminated.
Oh, don't get me started on C's null-terminated strings!
Stop feeding the troll please.
Parameter validation is a general thing done for security, whether that
be if you're using a variable in an include, database credentials,
connecting to a web service, etc. You need to make sure that those
basic conditions have a highly controlled set of values, not only for
security but to make
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.
1. Create an INI_ALL variable that means something like allow fopen
wrappers in include/require and default
Russell Nelson wrote:
Derick Rethans writes:
On Wed, 29 Jun 2005, Sara Golemon wrote:
Only intrinsicly safe if you've read the manual page to know that
badstring should have been null terminated.
Oh, don't get me started on C's null-terminated strings!
Stop feeding the troll please.
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.
1. Create an INI_ALL variable that means something like allow fopen
wrappers
Al Baker writes:
This thread's pretty much pointless - I recommend you read up on web
security in general.
I understand web security. When I found out that somebody was
breaking into my system, I knew *exactly* how they were doing it:
through PHP. I turned out to be correct. PHP's
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
Russell Nelson wrote:
And you're trying to tell me that PHP's 'include' doesn't have a problem??
The problem is not located on include, the problem is more general :
trusting user's data and PHP already provides tools to make it safe,
like file_exists(), htmlentities(), etc...
--
Etienne
Etienne Kneuss writes:
Russell Nelson wrote:
And you're trying to tell me that PHP's 'include' doesn't have a problem??
The problem is not located on include, the problem is more general :
trusting user's data
That's *also* a problem. Include's problem is a different one: that
no
Russell,
We got the point. Now please let internals@ continue to be productive and
focus on PHP development.
Sorry to be blunt but this thread is getting old and preventing us from
being productive.
Thanks,
Andi
At 12:58 AM 6/30/2005 -0400, Russell Nelson wrote:
Etienne Kneuss writes:
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
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
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'
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
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
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.
Uh, no. Affordances are the range of possible actions by a user,
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,
Mike Robinson writes:
Uh, no. Affordances are
Okay, I'm wrong about that. I don't need to push that analogy to make
my point.
You don't save people by filing down the sharp edges on a tool. You
do it by telling them it's sharp.
If you look at a tool, you can tell if it's sharp. If you
On 6/28/05, Russell Nelson [EMAIL PROTECTED] wrote:
If you have to read the man page to find out that 'include' will let
some random user from a third-world country execute 'rm -rf /' on your
server, then I propose that the problem is not that users didn't read
the man page. The problem is
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?
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
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
enabled
Why did both of my users miss that documentation? The facts seem to
be in opposition to your assertion that the
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
Just for the records, I guess you all know that I meant 'language
construct' where I wrote 'function' instead (in reference to include).
On 6/29/05, Nicolas Bérard Nault [EMAIL PROTECTED] wrote:
PHP is not, in my opinion, idiot-proof. You're right on that point.
Where our opinions differ is
Russell Nelson wrote:
Now, don't tell me that it's not insecure. Everyone here realizes
(and I know this because they've told me) that programmers who are
concerned about security will always check the values passed into
'include'. Why would they need to do that if 'include' wasn't
insecure?
Olivier Hill writes:
Are you suggesting that someone could wipe out your entire machine by
passing a remote script that would system('rm -rf /');?
It would only delete every file owned by the user that the webserver
runs as. On my server, that's 1846 files, some of which I'm fairly
attached
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
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
Russell Nelson wrote:
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
Hi,
On Sunday 26 June 2005 00:36, Yasuo Ohgaki wrote:
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
47 matches
Mail list logo
