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:
> Ru
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:
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...
--
Etie
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 maintain
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 reputat
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
>
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
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 de
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 s
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 pl
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 t
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
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 |
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 usi
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-ar
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
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.
[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
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 agre
[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. T
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 clo
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 ba
> -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 doin
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.
>
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 sup
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
Russell Nelson wrote:
> There is no problems with the include() statement. The only thing
> missing, is a tag in the docs ;)
If there were no problems, then why would a tag be needed?
He's trying to say, as I was - that the include() function works as
expected and is just fine as is but /ma
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
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
attach
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?
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
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 c
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 d
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
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?
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 probl
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 yo
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,
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, p
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
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
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' re
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 p
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 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 aga
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:
inc
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
