A few weeks back I asked for some help in dealing with a security breach
we had on one of our web servers. (See
https://lopsa.org/pipermail/tech/2011-January/005726.html.) Thanks to
some pointers from this list we were ultimately able to determine the
problem and get a patch from the vendor, but unfortunately I still don't
really understand the issue. Their patch added validation to a cookie
variable:
===
Replace the line below:
if(isset($_COOKIE['DMLANG']) &&
(file_exists(CLIENT_PATH.$_COOKIE['DMLANG']."/CON_".$thisfile))){
include(CLIENT_PATH.$_COOKIE['DMLANG']."/CON_".$thisfile);
with this line:
if(isset($_COOKIE['DMLANG']) &&
(preg_match("/^[A-Za-z0-9-]*$/",$_COOKIE['DMLANG'])) &&
(file_exists(CLIENT_PATH.$_COOKIE['DMLANG']."/CON_".$thisfile))){
include(CLIENT_PATH.$_COOKIE['DMLANG']."/CON_".$thisfile);
===
In our configuration the CLIENT_PATH constant is set to "client/". Given
that there was a $_POST payload, I'm assuming they somehow managed to
get it to include that payload (e.g. via including "php://input" or
something similar). I understand how they could do directory traversal
or insert a null byte to cause the php file function to ignore the stuff
after the string, but I can't figure out how an attacker could manage to
manipulate the string to a malicious value given that the variable they
control is appended to "client/". My concern here is they managed to
cause it to include some other already existing file that itself has a
security vulnerability. Any assistance in understanding this would be
appreciated. Thanks for all the help.
--
Thanks
Jefferson Cowart
[email protected]
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
