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]

Date: Fri, 4 Apr 2003 23:13:58 +0200 (CEST)
From: Sascha Schumann <sascha@...umann.cx>
To: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: An Alternate View of Recently Reported PHP Vulnerabilities


    Hello,

    let me add a number of points from my perspective as member
    of the PHP Group.

> What if the code looked something like this?
>
>   <?php
>     $num = $_REQUEST['num'];
>     str_repeat("A", $num);
>    ?>

    This is a violation of the trust model in which the
    application absolutely must not trust incoming data from the
    client.  Incoming data must be validated and proper bounds
    checking needs to be applied at the application level.

    It is not a specific issue of PHP; it is an issue all
    applications have to address which exist and operate in a
    dangerous and hostile world like the Internet.

    We all know, of course, that checks are often incomplete or
    even don't exist at all.  That is why PHP contains a built-in
    memory manager which enforces strict limits on resource
    consumption.  This significantly reduces the impact of
    incomplete input validation.

> How many otherwise innocent functions in PHP can have unexpected
> results if an attacker can control one of the parameters?

    An attacker should not directly control parameters in a
    correctly written application.  There should always be a
    validation layer between user input and application logic.

> 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.

    The PHP Group has initiated a semi-automated code coverage
    test system which verifies the correct operation of PHP
    functions when presented with uncommon input data.  The
    system has been extremely effective at uncovering issues and
    aiding developers in addressing these.

    The results of this measure will be available to our users as
    part of the next release, PHP 4.3.2.

    - Sascha