setup-config.php is tainted by request data

[hakre]

just stumbeled over it and think this should be prevented: setup-config.php uses relative include pathes. those can be manipulated by adding an additional slash after .php in the requests URL:

Example: ​http://example.com/wp-admin/setup-config.php/?step=1

relative file pathes should be based on ABSPATH which is defined there as well.

[hakre]

first patch.

[hakre]

same is for install.php. will extend the patch now.

[hakre]

install.php added.

[DD32]

slashes after the .php will not affect that at all.

PHP is smart enough to differentiate between file and url.

else /blog/2009/40/30/slug/ would screw over ../'s.. which it doesnt.

[hakre]

Replying to DD32:

slashes after the .php will not affect that at all.

PHP is smart enough to differentiate between file and url.

else /blog/2009/40/30/slug/ would screw over ../'s.. which it doesnt.

thought so as well until i head errors because of the requires. so this is tested and confirmed here.

i already asked myself how the hell that can happen. i doubt that this specific to php. maybe this is wordpress related? i will do some tests with plain php on the same server configuration but w/o wordpress.

[hakre]

I can only confirm that this does work with my php setup.

require_once('../samedir/otherfile.php');

that is influenced by it. if the test script is within samedir and otherfile.php exists, it will fail to include it when i add slashes behind the .php (=> .php/) as written in the ticket description.

this is PHP Version 5.2.8 CGI/FastCGI with Virtual Directory Support enabled. I'm not so shure if this is the cause, i could find this info about it:

Virtual Directory Support is ... related to the ... implementation of some file/directory macros used by zend/php and some php modules.
Virtual Directory Support off -> php relies on the c library functions for resolving the current working directory
Virtual Directory Support off -> php uses the tsrm implementation that keeps track of the current working directory on a per thread level.

​source

[hakre]

small testcase

[hakre]

added the files i used for the seperated test.

​http://host/samedir/file.php :

Hello World, this is file.php ... 
hello world, this is otherfile.php!

​http://host/samedir/file.php/ :

Warning: require_once(../samedir/otherfile.php) [function.require-once]: failed to open stream: No such file or directory in [...]\samedir\file.php on line 14

Fatal error: require_once() [function.require]: Failed opening required '../samedir/otherfile.php' (include_path='.;[...]\pear') in [...]\samedir\file.php on line 14

[DD32]

this is PHP Version 5.2.8 CGI/FastCGI with Virtual Directory Support enabled. I'm not so shure if this is the cause, i could find this info about it:

"Virtual Directory Support" is unrelated. I'm running 5.2.6 under Apache 2 on windows, And its fine.

to me, It sounds like a PHP/Web server bug.

However, Still This is a pointless bug to me - So what if you can access an bad URL by typing in a incorrect link to a automatically-redirected-to url?

[hakre]

yeah looks quite wired. think so it must be related to the webserver maybe but this is cgi so really the webserver? Apache 1.3.34 that is.

In the certain case I'm aware of, it is possibible to manipulate the path of files to be included. maybe ony the relative part. if inclusion is not possible script execution stops with a fatal error.

i do not rate this critical.

for overfall strictness it can make sense to include/require with CONSTs as it is done in other locations of the code. this does even prevent this pseudo (?) bug by doing something sensefull.

[Denis-de-Bernardy]

isn't WPINC defined in wp-settings? is it defined when we make it into setup-config.php?

[ryan]

(In [11301]) Use absolute paths for includes. Props hakre. fixes #9750