W3C File API gives web applications the functionality to work with objects and their data elements through drag and drop. Firefox 3.6 now supports File API. Given its potential, I decided to test the waters using Exif meta data. Most web applications read Exif meta data from JPEG images as a normal strings so in [...]
W3C File API gives web applications the functionality to work with objects and their data elements through drag and drop. Firefox 3.6 now supports File API. Given its potential, I decided to test the waters using Exif meta data. Most web applications read Exif meta data from JPEG images as a normal strings so in my demonstration today I will inject an iframe into the Exif description of my sample JPEG image.
The tools of the trade
- Firefox 3.6
- A basic JPEG image
- exiv2 – http://www.exiv2.org/
- Mozilla’s demo Exif web application
A simple XSS construction
I start with writing a real quick alert onload into a basic HTML file I will be hosting on the web. This will launch an alert box when the HTML loads in the users browser.
Contaminating the Exif metadata
Using a image metadata tool called exiv2, I inject the iframe into the JPEG image by simply writing to the ImageDescription. By calling exiv2 with the -pv flag, you notice the ImageDescription was successfully written.
Link: Sample image used in example
Testing the payload
For testing, we will use Mozilla’s own demo page using FileAPI and an Exif parser written by Jacob Seidelin. The page is located at: http://demos.hacks.mozilla.org/openweb/FileAPI/
When you drag and drop the contaminated image into the box in the web app, you immediately notice that the Exif data is parsed and processed without filtering. Since our injection was an iframe, it then loads content from our hosted file.
A quick and easy developer work around
Ok, since this exploitation isn’t really in FileAPI or Firefox 3.6 but rather the Exif parser within the web application, there isn’t much that can be done. Developers should always process strings through a filter before rendering it on a page. By doing this, you take complete control of how and what renders within your users browser eliminating the possibility of malicious code being executed.
UPDATE: 03/28/2010
After releasing to Full Disclosure, it was reported to Mozilla and they have since removed access to the demo site until it is fixed. I probably should have notified Mozilla myself but since it was just a silly XSS in a demo site, it didnt cross my mind.
Ref: https://bugzilla.mozilla.org/show_bug.cgi?id=555574
All Tags: browser, EXIF, exiv2, FileAPI, Firefox 3.6, injection, metadata, XSS
6 Responses
[...] This post was mentioned on Twitter by synopsi, Critical Security, Olivier Fortin, alex knorr, topsy_top20k and others. topsy_top20k said: [xss] Firefox 3.6 FileAPI .jpg Injection – http://tinyurl.com/yld4ceq [...]
Social comments and analytics for this post…
This post was mentioned on Twitter by iniqua_blog: [xss] Firefox 3.6 FileAPI .jpg Injection – http://tinyurl.com/yld4ceq...
[...] Firefox 3.6 FileAPI Exif Injection | iglobalonline [...]
Good catch. Fixed.
Is it just me or it does not look like XSS at all? – notice the title of the alert box shows a different URL than the location URL – i.e. you shouldn’t have access to cookies or to perform any actions on the target domain.
You are correct, in this example it is loading in the correct domain however that is only because I embedded an iframe which calls a remote file that executes the javascript rather then a local javascript execution. In the event a web application utilized a Exif reader and did not properly sanitize the data, it would in fact execute in the same domain as the page rendering.
Had I hosted the example, I would have execute the javascript locally rather then remotely.
Good call though, thanks for the feedback.