securfrog said:

> i guess you should learn some PHP before posting on bugtracks ...
>
>" net2ftp: a web based FTP client <= Remote File Inclusion "
>
>===> you should try your PoC before posting , there's no remote file
>include in that code ...


You are probably looking at recent versions, which don't have the
affected code at all.

The statements as quoted by the original researcher *do* appear in
versions of net2ftp before 0.7:

../net2ftp_v0.1/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.2/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.3/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.4/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.6/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.62/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.61/index.phpequire_once($application_rootdir . "/includes/browse.inc.php");
../net2ftp_v0.7/index.phpequire_once("./includes/browse.inc.php");

Notice how 0.7 doesn't use $application_rootdir.


For these older versions, we need to figure out where
$application_rootdir came from and if it's controlled by the attacker
at all.

In net2ftp_v0.62, settings.inc.php is included by index.php before
$application_rootdir, and settings.inc.php has:

$application_rootdir = dirname(__FILE__);

So, $application_rootdir should already be defined.

In 0.1, settings.inc.php has:

$server_rootdir = "/var/www/php/net2ftp"; // <-- The directory in which the net2ftp application files reside
...
$application_extension = ""; // (Do not use this, it is only for development purposes)
...
$application_rootdir = $server_rootdir . $application_extension;


So, $application_rootdir is defined in 0.1, too.


Given the large number of reports like this, it's not clear whether a
bunch of researchers are making erroneous grep-and-gripe claims
without checking their work, or if there's some obscure PHP scoping
bug that somehow allows variables to be overwritten in weird ways. I
haven't completely ruled out the latter but don't have any hard proof,
either.

- Steve