WPMU does not handle files with two or more dots in the filename

[Namely]

• WPMU does download images that have two or more dots in the file name

  E.g., One..jpg One...jpg One....jpg
  

rewrites do work (checked)

• this is clearly a WP issue:

  /wp-content/blogs.php
  

...
$file = BLOGUPLOADDIR . str_replace( '..', , $_GET[ 'file' ] );
if ( !is_file( $file ) ) {

status_header( 404 );
die('404 — File not found.');

}
...

WPMU removes two dots!!!

workaround:

$file = BLOGUPLOADDIR . $_GET[ 'file' ]; name.ly: workaround for files with two or more dots

tested and works fine

Errata, yes WPMU does download the files into the blogs.dir... but /wp-content/blogs.php does not handle them properly, hence, the files are not seen by the user.

Needs to be corrected.

X-Ref: #14937

The purpose of the str_replace was to prevent a request like /files/../../../../wp-config.php from being processed.

Probably $file = BLOGUPLOADDIR . str_replace( '../', , $_GET[ 'file' ] ); would work, but I haven't tested it.

I seem to be missing two quotes there

$file = BLOGUPLOADDIR . str_replace( '../', '', $_GET[ 'file' ] );

Anything
$file = BLOGUPLOADDIR . str_replace( '../', , $_GET[ 'file' ] );
or
$file = BLOGUPLOADDIR . str_replace( '/..', , $_GET[ 'file' ] );
or
$file = BLOGUPLOADDIR . str_replace( '/../', , $_GET[ 'file' ] );
would solve the issue.

The last one is enough. Any chance to see this change in the official release soon? Shame to miss it in 3.0.2.

I think we should 404 the request if it has a '../' in the request uri.

We are using:

$file = BLOGUPLOADDIR . str_replace( '../', '', $_GET[ 'file' ] );

If would be nice to have it in the next release, not to hack the code each time we run an upgrade.

Thank you.

Please do not change the version number. It's there to track when the bug was introduced/reported.

Also, the patch still looks valid and applies correctly.

Using validate_file() here would yield the same bug anyway. Curious if ".." rather than "../" could therefore prevent path traversal with "..\". Since this isn't a regression, I'm inclined to continue to punt it.

In IRC, we're wondering whether a backslash could cause some issues, either via traversal or by escaping characters.

The simple fix is to just not use .. in a URL. Punt.

Replying to nacin:

In IRC, we're wondering whether a backslash could cause some issues, either via traversal or by escaping characters.

The simple fix is to just not use .. in a URL. Punt.

For this one, I think the better solution is to sanitize the filename on upload and replace the .. with --.

This was more or less addressed by #19235. Recommending close.

Unfortunately, people will be running ms-files.php for the foreseeable future. Unlike global terms, moving away from ms-files.php is not easy. Some fixes to ms-files like this can be easy wins.