bugtraq - Re: An Alternate View of Recently Reported PHP Vulnerabilities

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20030405122339.A19298@cookie.hinet.hr>
Date: Sat, 5 Apr 2003 12:23:39 +0200
From: Goran Krajnovic <goran.krajnovic@...et.hr>
To: bugtraq@...urityfocus.com
Subject: Re: An Alternate View of Recently Reported PHP Vulnerabilities

On Thu, Apr 03, 2003 at 11:28:58PM -0500, Steven M. Christey wrote:
> As I said, I'm not familiar with PHP.  I welcome any clarifications or
> corrections.  But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.

There most certainly are more. Like I've already said, just browse through
the bug database at http://bugs.php.net and you'll find a large number of
bugs which result in the server process segfaulting. In fact, one of the
older ones I reported myself (http://bugs.php.net/15096) - in that case, all
it took for a segfault was sending a PHPSESSID cookie with the value of
session_id set to null. This was fixed in php 4.2.0.

My whole point in my first comment was that there is a large number of such
bugs in php, and they tend to change their behaviour on a version-to-version
basis. Posting each and every one here, even though they might be
exploitable, seemed pointless to me. And besides, the number of possible
different setups of PHP (different php versions, different web servers, cgi,
mod_php and compiled-in versions, etc) make it quite unlikely for an easy
and portable exploit (unlike, for example, SQL Slammer). The intruder would
first have to find a web site with an exploitable php application, and craft
an exploit particular for that site.

As a person who is both a php developer and who manages web servers, I don't
consider this to be a huge threat, but just another of php bugs which, when
reported to the bug database, will be fixed in future versions. Most
intrusions I've seen have been defacements done by simpler means through
popular forum and cms applications.

I agree that the reported vulnerability is a vulnerability and that it
potentially might be exploited, I just believe (famous last words...) the
threat level is low and that there are more such bugs known in php, and that
there are usually much much easier ways of exploiting web applications.

I hope this mail is not taken as criticising PHP developers as it is not
intended that way.

-- 
Goran Krajnoviæ,  dipl. ing.
[ Goran.Krajnovic@...et.hr ]
 Hrvatski Telekom - HThinet