On Mon, Aug 11, 2008 at 12:25 PM, Daniel Schwen <lists(a)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).
