Ticket #7211 (closed defect: invalid)

Opened 5 months ago

Last modified 2 months ago

Problems with media uploader

Reported by: pishmishy Assigned to: pishmishy
Priority: normal Milestone:
Component: Administration Version:
Severity: normal Keywords: mediauploader
Cc:

Description

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

06/30/08 13:46:15 changed by andy

Does changing the text of the button resolve the issue?

06/30/08 14:17:39 changed by pishmishy

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

06/30/08 14:20:17 changed by pishmishy

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/2.0.0.14 (Debian-2.0.0.14-2)

06/30/08 15:16:51 changed by pishmishy

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;
}
add_filter('flash_uploader','fc_no_flash');

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.

06/30/08 15:33:06 changed by pishmishy

  • 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.

06/30/08 16:24:59 changed by ryan

ModSecurity? 2.5.5 fixes compat with the uploader.

06/30/08 17:42:20 changed by pishmishy

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

07/01/08 08:09:38 changed by pishmishy

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 

http://www.theblog.org.uk/blog/../../../../../../../../../../../../../../../../../tmp/lolcat4.jpg

07/01/08 09:10:04 changed by pishmishy

  • priority changed from high to normal.
  • summary changed from Common mod_security rules, conflicts with media uploader to Problems with media uploader.

07/01/08 10:21:29 changed by pishmishy

  • keywords changed from mod_security apache mediauploader to mediauploader.

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 }}

07/01/08 10:23:25 changed by pishmishy

(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.

07/01/08 10:36:37 changed by pishmishy

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

/../../../../../../../../../../../../../../../../../tmp

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

07/01/08 10:50:06 changed by pishmishy

  • status changed from assigned to closed.
  • resolution set to invalid.
  • milestone deleted.

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

07/01/08 21:45:43 changed by Otto42

  • version deleted.

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

07/02/08 07:00:44 changed by pishmishy

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

James

09/12/08 20:01:40 changed by kaota

  • status changed from closed to reopened.
  • resolution deleted.

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?

09/12/08 20:28:59 changed by Otto42

  • status changed from reopened to closed.
  • resolution set to invalid.

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 </IfModule>

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