On 2012-02-08 02:21, Thijs Kinkhorst wrote:
On Tue, February 7, 2012 18:51, Filipus Klutiero wrote:
On 2012-02-03 07:16, Thijs Kinkhorst wrote:
On Thu, February 2, 2012 19:42, Filipus Klutiero wrote:
Hi Thomas,
On 2012-02-02 13:18, Thomas Goirand wrote:
On 02/03/2012 01:50 AM, Filipus Klutiero wrote:
That would leave the question, where is PHP functionality flawed if
it
is not in PHP's design?
That's a discussion that could be huge. Do you think that
README.Debian.security or even the Debian BTS, are places were we
should
discuss this? (or maybe you're not having this discussion, and regret
that the README.Debian.security leads to it?)
Sorry, there seems to be a misunderstanding. What I'm reporting is that
the current README contains a non-sensical item. Thijs has fixed the
problem, but the new version is also problematic. The new version would
say:
Security support will not be provided for flaws in functionality which
is not flawed in the design of PHP but can be problematic when used by
sloppy developers.
I also suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639230#25 that the
entire item be scrapped.
It's there because people report(ed) on security mailinglists, and CVE
names got assigned for, such issues. We want to make it clear that we
categorically do not treat those as vulnerabilities.
Could you please give examples, so we're all clear on the kind of
problem we're talking about?
What I am saying is that this wording will leave the reader puzzled; if
a flaw in a PHP functionality is not in PHP's design, the reader will
wonder where the flaw is.
In our view point the flaw is in sloppy application code. The part 'but
can be problematic when used by sloppy developers' indicates that to the
user.
I've changed 'developers' to 'application developers' to make it clear
that we're not referring to PHP upstream development here.
Fine, but that leaves the question equally unanswered.
If a flaw in PHP functionality is not in PHP's design, where is the
flaw? A flaw in PHP functionality is not in application code, sloppy or
not. PHP functionality exists independent of application code using it.
I do not agree that the question is unanswered. Example: The perceived
flaw is that someone claims on a sec mailinglist that untarring a tarball
which has ..-style paths using PHP's tar functions allows one to untar
files outside of the working directory, and according to them PHP should
prevent this. This flaw then gets a CVE name assigned. We on the other
hand are at the position that such a thing is not a flaw in PHP's design
but in the application code that is written sloppily not to check what
it's extracting. The anwser to your question is therefore: the flaw is in
the application code.
We provide some examples to illustrate that: putting untrusted data into
tar or unserialize functions without further checking may result in
adverse effects.
I see. Could you please provide example CVEs, or the names of the
specific relevant tar functions?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
