Image object injection vulnerability via 'buttonImageURL' parameter

[reedloden]

I've received a few reports today of an image object injection problem in swfupload affecting WordPress. I'm filing this public issue here after contacting swfupload-security@wordpress.org and being asked to do so (as this issue is already public knowledge).

There's an object injection "vulnerability" in swfupload, as shown by this demo URL:

https://wordpress.org/news/wp-includes/js/swfupload/swfupload.swf?buttonImageURL=http://1337day.com/img/logo_green.jpg

Known advisories for this issue:

http://1337day.com/exploit/20669
http://bot24.blogspot.com/2013/04/swfupload-object-injectioncsrf.html

This was tested on WordPress 3.5.2.

As discussed on e-mail, there are three basic options:

• Remove buttonImageURL
• Restrict buttonImageURL to same origin
• Ignore the issue

My recommendation would be to restrict buttonImageURL to the same origin as the blog site, as swfupload is already deprecated, and I'd rather it be secure but slightly broken than have a known issue that could be used for spoofing or other issues.

Thanks!

[nacin]

From an email sent by @nealpoole:

Do you have a proposed fix for the "object injection" issue? My initial thought is that the buttonImageURL parameter is working exactly as intended. The behavior is similar to a message board that allows you to embed images from third party websites. We could try to artificially constrain the image to the same domain as the SWF, but with open redirects and increased use of CDNs that change seems likely to break backwards compatibility and not serve as a complete fix.

From an email sent by me:

We agree with Neal that the image injection issue is more or less intended behavior, especially since fixing the XSS prevents a potential problem where the image can be used with XSS to help trick a user. The original reporter indicated a link between these issues as well, and we don't really see the image injection as a vulnerability in itself.

There are three ways to resolve this: 1) Remove support for buttonImageURL entirely. 2) Enforce the same domain for buttonImageURL. 3) Do nothing. None of these are perfect. Doing nothing does not entirely resolve the issue of trust, as you could use this to serve sketchy images from a trusted domain. The other options (removing buttonImageURL or enforcing the same domain) would indeed break current behavior, but the goal of our fork is for SWFUpload to be secure, not necessarily pretty and functional. But, having a button image is still pretty important. I've spoken to a few members of the WP security team and we're leaning toward WONTFIX for this, or if consensus ends up being same-domain, we can do that too.

From an email sent by Szymon Gruszecki:

consider another way to resolve "the issue": disable passing app parameters by URL. As I can see in current SWFUpload source code there are JS callbacks that allows to set these values - only parameter "moveName" cannot be set in another way than by FlashVars.

[msaffitz]

I've also filed http://core.trac.wordpress.org/ticket/24728#ticket as a solution for those of us who are happy to just turn off / remove swfupload and not use plugins that still depend on it.

We received a report of this issue today as well.

[anantshri]

for the time being those looking for a immediate solution just use below in .htaccess
<files swfupload.swf> order allow,deny deny from all </files>

[reedloden]

If you need to keep swfupload.swf accessible but want to prevent the use of the buttonImageURL parameter, something like this might work...

RewriteCond %{QUERY_STRING} (?:^|&)buttonImageURL=([^&]+) [NC]
RewriteRule ^wp-includes/js/swfupload/swfupload.swf$ - [R=404,L]

More issues, CVE's assigned: http://openwall.com/lists/oss-security/2013/07/18/10

[nealpoole]

@kseifriedredhat: CVE-2013-4145 / CVE-2013-4146 are incorrectly allocated.

1. It's a single issue, not two distinct issues. There isn't any CSRF issue, in fact: it's all tied to the XSS issue.
2. The XSS issue was fixed last year and assigned CVE-2012-3414 (https://nealpoole.com/blog/2012/05/xss-and-csrf-via-swf-applets-swfupload-plupload/)

[nacin]

@nealpoole: Yep. Here is the rest of the thread:

• http://openwall.com/lists/oss-security/2013/07/18/11
• http://openwall.com/lists/oss-security/2013/07/18/12
• http://openwall.com/lists/oss-security/2013/07/18/13

This issue therefore is CVE-2013-4144. 4145 and 4146 will be merged into CVE-2012-3414.

Please take discussion to oss-security so Steve/Andrew/etc can see it.

[mandricmihai]

Is this one fixed? https://wordpress.org/news/wp-includes/js/swfupload/swfupload.swf?movieName=%22]);}catch(e){}if(!self.a)self.a=!alert(1);//

[nealpoole]

@alexalexandru: Are you referring to https://nealpoole.com/blog/2012/05/xss-and-csrf-via-swf-applets-swfupload-plupload/? If so, it was patched several years ago.

[mandricmihai]

@nealpoole Yes, thanks for clarifying this one.