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.
[1] http://www.infoworld.com/article/08/08/01/A_photo_that_can_steal_your_online...
Is there any circumstance where Commons would validly host a Java file? If no, could this be filtered out in some way?
Joe
On Mon, Aug 11, 2008 at 9:25 AM, Daniel Schwen lists@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.
[1]
http://www.infoworld.com/article/08/08/01/A_photo_that_can_steal_your_online...
[[en:User:Dschwen]] [[de:Benutzer:Dschwen]] [[commons:User:Dschwen]]
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
I have added some text at [[Commons:Project scope/Proposal#Pdf and Djvu formats]] dealing with these based on the discussion on the talk page. Users are by no means unanimous about which files should be allowed, and I have tried to follow the majority opinion. Thus, the suggestion is that if a Pdf or Djvu file is educationally useful even to a single other Wiki it should be kept. Would you like to comment before this page goes live? Please do so at the bottom of the talk page.
Regards,
Michael
Thanks Michael for interesting suggestion, I added a comment there and my suggestion is to *split the discussion about PDF and djvu files* since they are very different, djvu files being much more "transparent" and usable.
Alex
2008/8/12 Michael Maggs Michael@maggs.name
I have added some text at [[Commons:Project scope/Proposal#Pdf and Djvu formats]] [...]
Michael https://lists.wikimedia.org/mailman/listinfo/commons-l
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.
If commons is vulnerable all wikimedia wiki's are and there is nothing that local commons users or admins can really do about this. Mediawiki should probablly be modified to check for garbage on the end of image files if it does not already do so.
Sending this on to wikitech-l so the devs can comment on it.
.
On Mon, Aug 11, 2008 at 12:25 PM, Daniel Schwen lists@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).
2008/8/11 Gregory Maxwell gmaxwell@gmail.com:
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).
AIUI the upload process checks both the extension and the magic number, doesn't it? I suppose it's a Simple Matter Of Programming to check files for validity ...
- d.
Please no scare mongering. Wikimedia sites are not vulnerable to this.
Yeah, sorry, but you know what they say about paranoid admins...
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
Well, that part works: http://commons.wikimedia.org/wiki/Image:Gifar.gif and test page at http://toolserver.org/~dschwen/test.html
try hard once I realize that the use of a different domain for uploading provided strong protection. It might well be that the upload
That is true. So there is no way to get to cookies at all? There are the wikipedia.org centralauth_Token and centralauth_User
would an applet not be able to read those in a browser that supports LiveConnect?
What the applet then would do with the cookies is another story.
AIUI, a GIFAR hosted on upload.wikimedia.org marked as a gif file can do anything with cookies that a standard applet could if hosted on upload.wikimedia.org. (if jar were a permitted file type) That *should* be limited to reading (and writing?) cookies for upload.wikimedia.org and .wikimedia.org neither of which have valuable cookies.
Not storing anything valuable under .wikimedia.org is why you have to go through [[special:userlogin]] manually for wikispecies and other smallish wikimedia.org subdomain wikis and you need to load a seperate image on [[special:userlogin]] for each of the larger wikimedia.org subdomains that you want to work automatically but Wikipedias and other projects with their own second level domain have SUL for all languages just by loading a single image; .wikipedia.org, .wikibooks.org, etc. do have valuable cookies.
--Jeremy
[[w:en:user:jeremyb]] (globally with SUL)
On Aug 11, 2008, at 6:41 PM, Daniel Schwen wrote:
Please no scare mongering. Wikimedia sites are not vulnerable to this.
Yeah, sorry, but you know what they say about paranoid admins...
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
Well, that part works: http://commons.wikimedia.org/wiki/Image:Gifar.gif and test page at http://toolserver.org/~dschwen/test.html
try hard once I realize that the use of a different domain for uploading provided strong protection. It might well be that the upload
That is true. So there is no way to get to cookies at all? There are the wikipedia.org centralauth_Token and centralauth_User
would an applet not be able to read those in a browser that supports LiveConnect?
What the applet then would do with the cookies is another story.
[[en:User:Dschwen]] [[de:Benutzer:Dschwen]] [[commons:User:Dschwen]]
On Mon, Aug 11, 2008 at 6:41 PM, Daniel Schwen lists@schwen.de wrote:
try hard once I realize that the use of a different domain for uploading provided strong protection. It might well be that the upload
That is true. So there is no way to get to cookies at all? There are the wikipedia.org centralauth_Token and centralauth_User
Check the upload domain again. ;)
There are no centeral auth tokens on wikimedia.org for a reason! :)
On Tue, Aug 12, 2008 at 8:22 AM, Aleksej deletesoftware@yandex.ru wrote:
Gregory Maxwell wrote:
There are no centeral auth tokens on wikimedia.org for a reason! :)
What about secure.wikimedia.org?
What about it? Many of the subdomains have tokens, but wikimedia.org itself does not. Secure, unfortunately, does not result in images being transferred via HTTPS.
(though good work by Daniel in figuring out how to exploit it using file path)
Gregory Maxwell wrote:
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 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.
All the same, I'd rather not have such files on our servers. I'm glad someone finally reported this, and it would have been nice if you filed a bug at the time.
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
-- Tim Starling
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
I'm not convinced yet that WikiMedia is not vulnerable! While at first the upload.wikimedia.org subdomain seemed to offer protection, my tests at
http://toolserver.org/~dschwen/test.html
indicate that when using the url http://commons.wikimedia.org/wiki/Special:FilePath/Gifar.gif to load the applet, it has no rights to connect to upload.wikimedia.org
Unfortunately it is late right now, so I don't have time to confirm if the server of origin is indeed set to commons.wikimedia.org as it seems at first glance, but if it is then I think I found an attack vector.
On Mon, Aug 11, 2008 at 11:29 PM, Daniel Schwen lists@schwen.de wrote:
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
I'm not convinced yet that WikiMedia is not vulnerable! While at first the upload.wikimedia.org subdomain seemed to offer protection, my tests at
http://toolserver.org/~dschwen/test.html
indicate that when using the url http://commons.wikimedia.org/wiki/Special:FilePath/Gifar.gif to load the applet, it has no rights to connect to upload.wikimedia.org
Unfortunately it is late right now, so I don't have time to confirm if the server of origin is indeed set to commons.wikimedia.org as it seems at first glance, but if it is then I think I found an attack vector.
If there is away around it (via things like the file path redirect) then it would be very good to figure that out. I hadn't considered that set of possibilities at all.... if thats the case then it's more of a concern than just gifar... there are several other ways to upload browser-executable code (even java)... But it's been the standing belief that the domain and IP separation provided protection.
Daniel Schwen wrote:
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
I'm not convinced yet that WikiMedia is not vulnerable! While at first the upload.wikimedia.org subdomain seemed to offer protection, my tests at
http://toolserver.org/~dschwen/test.html
indicate that when using the url http://commons.wikimedia.org/wiki/Special:FilePath/Gifar.gif to load the applet, it has no rights to connect to upload.wikimedia.org
Unfortunately it is late right now, so I don't have time to confirm if the server of origin is indeed set to commons.wikimedia.org as it seems at first glance, but if it is then I think I found an attack vector.
Does anyone actually use Special:FilePath? This is not the first security hole opened up by it, and the API could easily serve the same purpose. Could it be removed?
-- Tim Starling
Eh? The API, sure in context of an application, but whatabout interwiki. But more importantly: http://wikia.com/index.php?title=Template:WikiLogo&action=edit
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)
Tim Starling wrote:
Daniel Schwen wrote:
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
I'm not convinced yet that WikiMedia is not vulnerable! While at first the upload.wikimedia.org subdomain seemed to offer protection, my tests at
http://toolserver.org/~dschwen/test.html
indicate that when using the url http://commons.wikimedia.org/wiki/Special:FilePath/Gifar.gif to load the applet, it has no rights to connect to upload.wikimedia.org
Unfortunately it is late right now, so I don't have time to confirm if the server of origin is indeed set to commons.wikimedia.org as it seems at first glance, but if it is then I think I found an attack vector.
Does anyone actually use Special:FilePath? This is not the first security hole opened up by it, and the API could easily serve the same purpose. Could it be removed?
-- Tim Starling
On Mon, Aug 11, 2008 at 9:44 PM, Tim Starling tstarling@wikimedia.org wrote:
Gregory Maxwell wrote:
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 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.
All the same, I'd rather not have such files on our servers. I'm glad someone finally reported this, and it would have been nice if you filed a bug at the time.
Even if Wikimedia is not vulnerable, many other MediaWiki installations will be.
I wasn't able to produce a SUN JRE executable gif that I could upload at the time, since anything I got sun to execute failed magin.. but then again the full exploit was "secret".. So I saw no bug to file.
.... taking another related vulnerability off list then...
Daniel Schwen 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.
Wiki-Bot has been updated to detect them. More exactly, it is now looking case-insensitively for manifest.mf (a jar without a manifest would be inocuos, isn't?)
This adds to its duties of verifying the uploaded files type (gif verification is quite lax, but you won't be able to append anything to a png without triggering a "wrong png" warning), check for embedded rar files (very similar to this case) and notification of deleted files being reupload.
If only the admins joined at #commons-image-uploads ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides wrote:
| If only the admins joined at #commons-image-uploads ...
Taking a look in there it seems that there's two bots doing the same work. I noted that Wiki-bot inlcudes reuploads whereas Cubbie2 doesn't. ~ Is there something special that Cubbie2 does that Wiki-bot doesn't?
Just saw something--Cubbie2 highlights certain strings like [Ll]ogo. Can we combine the functions into one bot?
- -- Cary Bass Volunteer Coordinator
Your continued donations keep Wikipedia running! Support the Wikimedia Foundation today: http://donate.wikimedia.org Wikimedia Foundation, Inc. Phone: 415.839.6885 x 601 Fax: 415.882.0495
E-Mail: cary@wikimedia.org