David Zülke writes:
> I don't care about the thousands of idiots out there who are too
> dumb to avoid security leaks.
You don't have to be very dumb to create a whopping big security hole.
It should be *hard* to create a security lapse which causes hostile
code to run on your server. 'include
Okay, I'm leaving for vacation in 7 hours. I'd like to bring the
'include' discussion to an end. There have been a lot of weak points
made, e.g. "Yeah, it's a problem; that's why we documented it".
Rather than re-dismiss them, I'll ignore them in favor of addressing
the strongest ones.
o This
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"
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
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
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
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
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.
> ...
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
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?
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
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
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
Nicolas Bérard Nault writes:
> Correctly using the include clause is the programmer's responsability.
And yet ... I keep going back to the fact that people don't use it
correctly. It's a fact that many people use 'include' incorrectly.
If you say that the people are wrong, then you are asking p
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
Ron Korving writes:
> Personally, I think include is just fine the way it is.
Google for "php security flaw". Do you think *that's* fine the way it
is?
Clearly, the fact that you can turn this behavior off suggests that
somebody has noticed that it's badly designed. Rather than say, as
some pe
Unknown W. Brackets writes:
> Why not simply disable allow_url_fopen on your server or servers?
Why don't people do that? Obviously ... they don't.
If you have no other answer than "Maybe they don't care about
security, maybe they're stupid, maybe they're native", then may I
suggest that the pr
23 matches
Mail list logo
