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 problem is decreasing in frequency according to vulnerability
reports, so there is no urgency about fixing it.
People aren't going to report vulnerabilities when they are
persistently told "That's not a bug; that's a feature!"
Vulnerability reports are self-selected and thus are not a good
sample for even the most rudimentary statistical analysis like "the
rate is decreasing."
o If you trust user data you are eventually going to get screwed; if
not by 'include' then by something else.
It's not obvious that 'include' can be convinced to execute remote
code.
o We're not fixing it.
This is simultaneously a weak point and a very strong one.
Obviously the maintainer of a codebase can publish code with any
number of vulnerabilities in it and nobody can do anything about it
other than to stop using the code. On the other hand, the code is
still vulnerable, so not fixing it is no solution.
o We are fixing it, but just not your way.
Depending on the exact nature of the fix, this may be a reasonable
response. The fix needs to address the problem that 'include' has
hidden sharp edges. If it merely offers a way to optionally cover the
sharp edge, then it won't fix the problem. Other optional fixes
(e.g. allow_url_fopen==false) haven't yet fixed the problem. Why
should this one fix it?
--
--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:
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...
Russell, no offense, but the developers, and many random other people
have attempted to stop this conversation many times. This is not a
debate, it is not a college speech class, there are no "points" to make.
Regardless of whether or not you like the answer, the answer is no.
Enjoy your vacation---I know we will. ;)
--
Shaun M. Thomas INN Database Administrator
Phone: (309) 743-0812 Fax : (309) 743-0830
Email: sthomas@townnews.com Web : www.townnews.com
Fookin' Jaysus man. It is a feature, not a vulnerability. It starts
getting a weak point when stupid high school kiddies who "know PHP well"
start coding something ("this boy's as good as a professional, only way
cheaper") that introduces a vulnerability because they are drop dead stupid.
That's the problem. I don't care about the thousands of idiots out there who
are too dumb to avoid security leaks. If they don't know how to code
properly - who cares? It's good for you, since the company who hired the
idiot back then now knows better and will come to you. And you know how to
avoid these security problems. What's the point of this entire discussion
for Pete's sake. You can just as well stab your eye out with any fork in the
world, and that's not a reason to abolish them, right? The discussion is
stupid, and it did nothing but waste helluva lot of bandwidth.
- David
-----Original Message-----
From: Russell Nelson [mailto:nelson@crynwr.com]
Sent: Thursday, June 30, 2005 7:15 AM
To: internals@lists.php.net
Subject: [PHP-DEV] Bringing the 'include' discussion to an endOkay, 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 problem is decreasing in frequency according to vulnerability
reports, so there is no urgency about fixing it.People aren't going to report vulnerabilities when they are
persistently told "That's not a bug; that's a feature!"
Vulnerability reports are self-selected and thus are not a good
sample for even the most rudimentary statistical analysis like "the
rate is decreasing."o If you trust user data you are eventually going to get screwed; if
not by 'include' then by something else.It's not obvious that 'include' can be convinced to execute remote
code.o We're not fixing it.
This is simultaneously a weak point and a very strong one.
Obviously the maintainer of a codebase can publish code with any
number of vulnerabilities in it and nobody can do anything about it
other than to stop using the code. On the other hand, the code is
still vulnerable, so not fixing it is no solution.o We are fixing it, but just not your way.
Depending on the exact nature of the fix, this may be a reasonable
response. The fix needs to address the problem that 'include' has
hidden sharp edges. If it merely offers a way to optionally cover the
sharp edge, then it won't fix the problem. Other optional fixes
(e.g. allow_url_fopen==false) haven't yet fixed the problem. Why
should this one fix it?--
--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.
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' makes it trivial.
The discussion is stupid, and it did nothing but waste helluva lot
of bandwidth.
Actually ... this discussion established firmly that PHP's insecurity
is designed-in as a feature. Anybody reading the archives will
understand that PHP and security will forever be strangers to each
other.
Sorry, Rasmus, for calling a spade a spade, but it needs to be said
even if you don't like it.
--
--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.