Cenzic 232 Patent
Paid Advertising
web application security lab

Firefox Save As Complete Issue

What you download may not be what you saw initially when you use the Web Page Complete option to save an HTML page in Firefox. I’m not sure if this is a bug or not, but it’s probably not desired behavior. I built a quick demo to show the issue. If you download the file using the “complete” option in Firefox it actually saves the images that are outputted via JavaScript and actually modifies the HTML of the page to include the hard link to the image tag.

Not only does it change the aesthetic of the page but it actually modifies the HTML on the page (something that has actually broken certain experiments in the past). So let’s turn the mild annoyance into an exploit - if you know you only had X amount of images on the page in question and you see that the amount of images on the page are greater than X you know the page has been saved and is being run in local context, without having to actually query the drive or do anything else suspicious. At that point you can begin the construction of your exploit with local drive access.

The moral of the story is don’t save anything to your drive and run it unless you completely trust the source of the HTML.

4 Responses to “Firefox Save As Complete Issue”

  1. Ivan Says:

    Interesting, this means that we can exploit networks (admins stations) throught a little social engenering even offline … ?

    Scenario: “Put some vuln code/file into some machine on the network where we have access, give url/file to admin witch contains some interesting content for him and also our home made code for “calling” our vuln code from network.”

  2. Jungsonn Says:

    It’s cool, I’ve been playing with this idea in my mind for some time, but never actually tried it. Nice to see that it can actually work. Good job :)

  3. pdp Says:

    Well you don’t really need to check the DOM in order to start the exploit. just enclose it within a try .. catch .. block. For example

    try {
    send_registry_to_a_remote_location();
    } catch (e) {}

    easy? I had a very quite a lot of fun with this type of attack vector, mainly around the XSS issue that David Kierznowski and I found in Sage RSS Reader. Sage eats the feeds and transforms them with XSLT. The transformed document is saved on the disk inside a Temp folder. So when the user read their feeds, they are actually accessing a document from C:\ for example. Unfortunately, because of this XSS problem, JavaScript code was copied from the XML feed into the generated HTML document. This is very nasty. Now attackers can read any file on the local disk. Quite cool!

  4. Aviv Says:

    To make this exploit cross-browser (work in IE too.. haven’t checked other browsers), you can just compare the length of document.all to the remote value.
    In this case:
    if (ie) len=13; if (firefox) len=12;
    if (document.all.length!=len) alert(”exploit would have happened”);

    pdp is right, though.. If you know that it will be possible to exploit something, just try to exploit it.