bugtraq - Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200604120029.k3C0Tb03015839@cairo.mitre.org>
Date: Tue, 11 Apr 2006 20:29:37 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: Re: function *() php/apache Crash PHP 4.4.2 and 5.1.2

Michal Zalewski asked:

>...but how come there's no CVE entry for the bash script in my
>signature?

To which I'll answer the underlying question, i.e. "why assign a CVE
identifier to what appears to be a non-vulnerability?"

1) To clarify: while we changed the CVE naming scheme in October 2005
   so that the "CAN" prefix is no longer used, there is still a
   conceptual difference between candidates and entries.  The number
   in the advisory was (and is) a candidate [1].  Any candidate can be
   rejected in the future if there is sufficient dispute - along with
   a record of the dispute itself.

2) The candidate number was reserved pre-disclosure; the researcher is
   responsible for verifying the issue and working with the vendor
   before disclosure.  SecurityReason can clarify the nature of their
   interaction with PHP, and their rationale for publishing this
   issue.

3) One does not expect an interpreted language to segfault, and there
   have been enough issues in the past couple years in which people
   have casually dismissed resource-focused "DoS" attacks that turned
   out to be buffer overflows, array index errors, or other memory
   corruption problems.  This can only be proven with deeper analysis;
   the simplicity of an attack is not evidence itself, as your own
   research recently highlighted with an obvious attack on script
   handlers in IE, which exposed a much more interesting vulnerability
   underneath.

4) SecurityReason's advisory does not state the specific impact of the
   issue.  However, what if the entire Apache server could be caused
   to crash?  If the server is supporting multiple users, then this is
   not just a self-DoS.  The vulnerability becomes context-dependent.

5) Interpreted languages could conceivably be held to a higher
   security standard than applications written in those languages.
   Suppose that this segfault is actually exploitable in some sense.
   If a PHP application can be manipulated into making recursive
   calls, then it might become exploitable - remotely if the
   application happens to be remotely accessible.  Recall the the Perl
   interpreter format string vulnerability, which is also
   context-dependent since it depends on the existence of vulns in
   Perl apps to even succeed.

6) The scenarios listed in (3) through (5) might seem unlikely, but
   not impossible.  Without deeper analysis, we cannot be sure.

- Steve

[1] Note: the distinction between candidates and entries is currently
    blurred and under review, since the old process of voting became
    too unwieldy due to the growing volume of candidates.