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 agree that these issues ideally should not get CVE names reported against PHP at all, but hey, it happens. Thijs -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
