[Commons-l] GIFAR vulnerability and commons

[Gregory Maxwell]

On Mon, Aug 11, 2008 at 12:25 PM, Daniel Schwen <lists at schwen.de> wrote:
> A more (or less) new form of exploit has just been published [1]. By appending
> a Java-Archive (JAR) file to an Image file (JPG/GIF) a hybrid file can be
> created which will validate as both a valid JAR and a valid image.
>
> The file can be uploaded to an image host and included as a Java-Applet on any
> page on any host. The applet will have privileges to connect back to the
> originating host and operate with all the account holders privileges.
>
> Commons seems to be a target for such an attack. Upload is easy, although I'm
> not to sure about the damage potential. I suppose if an administrators
> account would get compromised an applet could be manufactured to mass delete
> content or mass block users.
>
> Anyhow. I was just surprised that nobody posted this already.

Please no scare mongering. Wikimedia sites are not vulnerable to this.

I reproduced the vulnerability the day it hit Slashdot and determined
that it posed no special risk to us.

The attack works like this.
I upload eviljar.gif to  socialnetwork.com  the file is now available
at www.socialnetwork.com/images/2398BA8924F3295.gif.  I then setup a
webpage http://evildomain.com/foo.html  which contains the java embed
code for the "gif" file over at socialnetwork.com.   Innocent users
then visit evildomain.com/foo.html  and load and execute the java
which now has permissions to act on behalf of the user over at
socialnetwork.com where it can steal cookies and impersonate them.

The reason that Wikimedia sites are not vulnerable is that wikimedia
sites confine all user uploaded files to upload.wikimedia.org which
holds nothing but these files.   XSS attacks via uploaded files (which
is what this effectively is, though it's using Java) end up confined
by browser behaviour to only access that particular domain (or IP, in
the case of Java). Since there is nothing worth targeting on that IP
(no login, no cookies, no forms, etc) it couldn't do much.

What I wasn't able to reproduce is a file which both passed the upload
validation and which was executed by the Sun JRE... though I didn't
try hard once I realize that the use of a different domain for
uploading provided strong protection. It might well be that the upload
validation needs to be made more aggressive to stop these files, but
they pose us little to no risk. (Right now about the only risk I can
see would be having evildomain instruct browsers to DOS attack our
image servers... which could be done with simple JS on evildomain
without any exploit at all).