Likes Likes:  0
Resultaten 1 tot 3 van de 3
Geen
  1. #1
    Sascha Schumann
    Re: An Alternate View of Recently Reported PHP Vulnerabilities
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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

  2. #2
    Goran Krajnovic
    Re: An Alternate View of Recently Reported PHP Vulnerabilities
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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@Hinet.hr ]
    Hrvatski Telekom - HThinet

  3. #3
    dullien@gmx.de
    Re: An Alternate View of Recently Reported PHP Vulnerabilities
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: An Alternate View of Recently Reported PHP Vulnerabilities

    Hey Steven , all,

    SMC> How many people who audit PHP applications verify that the second
    SMC> argument to str_repeat() is valid?

    Nobody, because the misbehaviour of this given function is a _bug_ and
    thus not documented. Without documenting the valid input ranges, there
    can be no "validation", only "guessing that this is now valid".

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

    Expect the same to hold true for almost any other language. The libc's
    these days are relatively "bug-free", but the libraries of PHP etc.
    have not undergone the same amount of auditing.

    SMC> And maybe entire classes of vulnerabilities that are assumed to be
    SMC> specific to a particular language, aren't.

    Any vulnerability existing in C is very likely going to occur in other
    languages which (in the end) chain down to C-like code.

    Cheers,
    dullien
    PS: Let us please just keep the entire Java discussion out of this


    --
    Mit freundlichen Grüssen
    dullien@gmx.de mailto:dullien@gmx.de


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics