[php-maint] Bug#658208: Bug#658208: Bug#658208: Bug#658208: Bug#658208: [php5] README.Debian.security: "problems used by sloppy developers"

[Thijs Kinkhorst]

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