RE: Re: SWFUpload <= (Object Injection/CSRF) Vulnerabilities Multiple flaws

["Christey, Steven M." <coley () mitre org>]

Kurt said:

> So to confirm:
>
> CVE-2013-4144 swfupload KedAns-Dz object injection
> CVE-2013-4145 duplicate of CVE-2012-3414
> CVE-2013-4146  swfupload KedAns-Dz CSRF

That is how we're handling it for CVE right now, although since people aren't sure whether there's really a CSRF, I'm 
waiting to update CVE-2013-4146 until we get more clarity.

I'm also not sure what the real problem is with the "object injection" in this case.  This appears to be an example of 
"content spoofing" as defined by OWASP/WASC, but using images instead of rendering attacker-controlled text.

It looks like a URL can be used to change the image that's displayed for a Flash button through the upload object 
itself.   This is not technically XSS because there is no script being used, but apparently it affects how the upload 
interface is presented to the victim.

It's not immediately clear to me whether there are phishing-style or clickjacking-style attacks that can be performed 
against SWFUpload by using a malicious button image.  Just printing out an unexpected image onto the form wouldn't 
cross privilege boundaries by itself I don't think, because the attacker already got the victim's browser to render the 
SWFUpload dialog that shows the button in the first place, and the SWFUpload functionality appears to be intended to 
allow remotely-specified images based on the buttonImageURL parameter and documentation for the .  If the button can be 
used to submit a file without interaction or trick the user in some other way, that might be sufficient for a CVE.

- Steve