Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#7211 closed defect (bug) (invalid)

Problems with media uploader

Reported by: pishmishy Owned by: pishmishy
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords: mediauploader
Focuses: Cc:


I've a customer who's having problems with mod_security and WordPress. This manifests itself in the new media uploader. Whilst there's a published workaround using .htaccess (see http://wordpress.org/support/topic/164999), their host won't allow them to bypass the global mod_security settings in this way.

There's a not-unpopular set of mod_security rules for securing WordPress that haven't been uploaded to cater for 2.5.1 (http://blogsecurity.net/wordpress/modsecurity-and-wordpress-defense-in-depth/).

I'm still looking to root out all the conflicts I can spot but in the first instance

SecFilter "insert[[:space:]]+into"

which is designed to protect against SQL injections, matches against the "Insert into Post" button and blocks the HTTP request (this appears to be a common rule outside of the WordPress specific paper referenced above).

Change History (17)

#1 @andy
14 years ago

Does changing the text of the button resolve the issue?

#2 @pishmishy
14 years ago

Andy, yes. I've been in touch with the author of those mod_security rules and he's in the process of updating them.

#3 @pishmishy
14 years ago

I think we're seeing the same problem as #6278. I'm not sure what my customer is using but I'm seeing the problem with:

Iceweasel/ (Debian-

#4 @pishmishy
14 years ago

This may not be flash related, and so different to #6278. I wrote a short plugin to disable the flash uploader.

function fc_no_flash () {
	return false;

but the normal upload form fails too. The user is directed to the attributions/insertion form as you'd expect, but there's no thumbnail and most importantly the file hasn't been uploaded. I'm continuing to investigate.

#5 @pishmishy
14 years ago

  • Status changed from new to assigned

My customer has this "HTTP Error problem" with
Firefox 3.0 and
IE 6.0.2900.2180.xpsp.sp2_gdv.070227_2254

So I'm pretty sure it's not browser related either. I'm hoping to receive a copy of the host's mod-security configuration.

#6 @ryan
14 years ago

ModSecurity 2.5.5 fixes compat with the uploader.

#7 @pishmishy
14 years ago

Do you know why it fixes it/what the bug actually is?

#8 @pishmishy
14 years ago

I think that the uploader may be trying to put the image into a strange location. After attempting to upload the image it thinks the thumbnail is in http://www.theblog.org.uk/tmp but puts the LINK URL as


#9 @pishmishy
14 years ago

  • Priority changed from high to normal
  • Summary changed from Common mod_security rules, conflicts with media uploader to Problems with media uploader

#10 @pishmishy
14 years ago

  • Keywords mod_security apache removed

Prior to wp_handle_upload():
File_ID = async-upload
name = lolcat.jpg
tmp_name = /tmp/phpul5Gxa
Results of wp_handle_upload(){
filename /../../../../../../../../../../../../../../../../../tmp/lolcat6.jpg
URL http://www.theblog.org.uk/blog//../../../../../../../../../../../../../../../../../tmp/lolcat6.jpg

#11 @pishmishy
14 years ago

(sensibly formatted this time) Prior to wp_handle_upload():

File_ID = async-upload
name = lolcat.jpg tmp_name = /tmp/phpul5Gxa

Results of wp_handle_upload()

filename = /../../../../../../../../../../../../../../../../../tmp/lolcat6.jpg 
URL = http://www.theblog.org.uk/blog//../../../../../../../../../../../../../../../../../tmp/lolcat6.jpg }}}
Looks like it's not determining the upload location correctly for some reason.

#12 @pishmishy
14 years ago

In wp_handle_upload()'s call to wp_unique_filename $uploadspath? is being set to


That's not right, and I'm not surprised if mod_security complains about it!

#13 @pishmishy
14 years ago

  • Milestone 2.7 deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

upload_dir was set incorrectly. All this work... doh! At least I'm now familiar with the new uploader =)

#14 @Otto42
14 years ago

  • Version 2.5.1 deleted

Warning! The /../../../ thing in the upload_dir is usually a good sign that you've been hacked.

#15 @pishmishy
14 years ago

They had been - I just missed it when I cleaned up with a new install.


#16 @kaota
13 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

This thread is WAY off topic. Coming back down to earth...

I'd like to re-open this, as it still hasn't solved the problem for those of us who develop on platforms we cannot control. I've manually patched my wp-admin/media.php to change the button name, but I'll have to do this every time I update unless it's fixed in the source. I see that there's some new mod_security rules to help here, but what are we supposed to do when we cannot control mod_security or its rules, short of changing the button name?

#17 @Otto42
13 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

If mod_security is configured stupidly, then that is not WordPress's problem and WordPress should not have to not use the word "insert" in order to deal with it.

Why don't you disable mod_security in the admin folder? Make an .htaccess file in there and put this in it:
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off

However, this is not a valid ticket. If you have an actual bug to report, report that separately.

Note: See TracTickets for help on using tickets.