bugtraq - Re: dotproject <= 2.0.1 remote code execution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 15 Feb 2006 08:54:52 +1100
From: Adam Donnison <adam@...i.com.au>
To: r.verton@...il.com
Cc: bugtraq@...urityfocus.com
Subject: Re: dotproject <= 2.0.1 remote code execution


I'm not sure I understand why this is a problem.  As you have stated 
register_globals must be set to on before any of this can be triggered. 
  In terms on register_globals being on by default, that hasn't been the 
case in PHP for quite some time.

Also, I am intrigued by the claim that 'protection.php' is vulnerable. 
There is no 'protection.php' anywhere in the dotProject tree.

As pointed out to you privately, the simple solution is to turn 
register_globals off.

Adam Donnison
Admin - dotProject

r.verton@...il.com wrote:
> dotproject <= 2.0.1 remote code execution
> ======================================
> 
> 	Software: dotProject <= 2.0.1
>    	Severity: Arbitrary code execution, Path/Information Disclosure
>    	Risk: High
>    	Author: Robin Verton <r.verton@...il.com>
>    	Date: Feb. 14 2006
>    	Vendor: dotproject.net [contacted]
> 
> 	Description:
> 	 dotProject is a volunteer supported Project Management application.
> 
> 	Details:
> 	 The 'protection.php' script does not properly validate user-supplied input in the 'siteurl' parameter.
> 	 Some user-supplied input is not checked correctly so an attacker can include a remote php file and
> 	 execute arbitrary phpcode or arbitrary system command via eval().
> 
> 	 Because there are over 10 Bugs I only post the vulnerable files + parameters which are not checked.
> 	 To exploit these vulnerables register_globals have to be set ON (default).
> 
> 	 1) /includes/db_adodb.php?baseDir=[REMOTE INCLUDE]
>  
> 	 2) /includes/db_connect.php?baseDir=[REMOTE INCLUDE]
>  
> 	 3) /includes/session.php?baseDir=[REMOTE INCLUDE]
> 	 
> 	 4) /modules/projects/gantt.php?dPconfig[root_dir]=[REMOTE INCLUDE]
>  
> 	 5) /modules/projects/gantt2.php?dPconfig[root_dir]=[REMOTE INCLUDE]
>  
> 	 6) /modules/projects/vw_files.php?dPconfig[root_dir]=[REMOTE INCLUDE]
>  
> 	 7) /modules/admin/vw_usr_roles.php?baseDir=[REMOTE INCLUDE]
>  
> 	 8) /modules/public/calendar.php?baseDir=[REMOTE INCLUDE]
>  
> 	 9) /modules/public/date_format.php?baseDir=[REMOTE INCLUDE]
>  
> 	 10) /modules/tasks/gantt.php?baseDir=[REMOTE INCLUDE]
> 
> 	 There are also some path discolsure bugs:
> 
> 	 Nearly ALL files in /db/ give out some nice php-errors by accessing them directly with the parameter
> 	 baseDir=foobar.
> 
> 	 Then, if the /doc/ directory is not deleted (default) you can access to two varoius files which
> 	 disclose you some system informations:
> 
> 	 1) /docs/phpinfo.php - A phpinfo() file.
>  
> 	 2) /docs/check.php - Some more informations about the installed dotProject.
> 
> 	Solution:
> 	 Turn register_globals OFF, delete the /docs/ dir and cover /db/ dir with an htaccess.
> 
> 	Timeline:
> 	 24.01.2006 - Bugs found
> 	 26.01.2006 - Vendor Contacted
> 	 14.02.2006 - Publishing
> 
> 	Credits:
> 	 Credits go to Robin Verton (r.verton [at] gmail [dot] com)
> 	 


-- 
Adam Donnison                                  email: adam@...i.com.au
Saki Computer Services Pty. Ltd.
93 Kallista-Emerald Road                        phone: +61 3 9752 1512
THE PATCH  VIC 3792    AUSTRALIA                fax:   +61 3 9752 1098