My second thought was: the Browser Security Handbook documents several “pseudo-protocol” which can contain other files in them that can be directly adressed from the browser. Although support for them is rather spotty, I thought that using JAR (supported by Firefox) and MHT (supported by IE) I could cover a large gamut of users.

The results are rather disappointing, but I document the failure sources which I isolated, maybe it can help someone out.

First of was JAR. JARs are in fact just zip files, so creating them is very straight forward. After creating and testing it locally, I uploaded the archive and tried to access it like this (if you have NoScript, you must add it to the whitelist for it to work):

jar:http://ghdb.mirror.googlepages.com/ghdb.jar!/_0toc.html

Just to get the following error message:

Unsafe File Type

The page you are trying to view cannot be shown because it is contained in a file type that may not be safe to open. Please contact the website owners to inform them of this problem.

After searching for the error message and not coming up with anything useful, I took a stab at looking at the source code, this is one of the reasons open source is great after all.

• This is the resource file with the error message.
• This is where it is used to generate the error page.
• And this is the file which generates the error code: nsJARChannel.cpp (scroll to line 771 to see the relevant code).

From the code:

// We only want to run scripts if the server really intended to
// send us a JAR file.  Check the server-supplied content type for
// a JAR type.
...
mIsUnsafe = !contentType.EqualsLiteral("application/java-archive") &&
            !contentType.EqualsLiteral("application/x-jar");
...
if (prefs) {
    prefs->GetBoolPref("network.jar.open-unsafe-types", &allowUnpack);
}

if (!allowUnpack) {
    status = NS_ERROR_UNSAFE_CONTENT_TYPE;
}

Ignoring the fact that the code uses negative assertions (ie. mIsUnsage) rather than positive assertions (ie. mIsSafe), the code tells us that they are looking for the correct Content-Type sent by the webserver or, alternatively, for the “network.jar.open-unsafe-types” setting. This is probable to prevent the GIFAR attack. So, it seems that the googlepages server doesn’t return the correct Content-Type. We can quickly confirm it with the command:

curl http://ghdb.mirror.googlepages.com/ghdb.jar --output /dev/null --dump-header /dev/stdout

And indeed the result is:

HTTP/1.1 200 OK
Last-Modified: Wed, 31 Dec 2008 11:25:06 GMT
Cache-control: public
Expires: Fri, 09 Jan 2009 10:54:28 GMT
Content-Length: 2700935
Content-Type: application/octet-stream
Date: Fri, 09 Jan 2009 10:54:28 GMT
Server: GFE/1.3
...

So the options would be to (a) tell people to lower their security or (b) not use Google’s server, none of which was particularly attractive.

Now lets take a look at the MHT format. As many other MS formats, it is very sparsely documented (all hail our closed-source overlord), although there were some standardization efforts. Anyway, here is the Perl script I’ve thrown together to generate an MHTML file from the mirror:

use strict;
use warnings;
use File::Basename;
use MIME::Lite;
use File::Temp qw/tempfile/;
use MIME::Types;


my $mimetypes = MIME::Types->new;
my $msg = MIME::Lite->new(
        From    =>'Saved by Microsoft Internet Explorer 5',
        Subject =>'Google Hacking Data Base',
        Type    =>'multipart/related'
    );

my $i = 0;
my @tempfiles;
opendir my $d, 'WEB';
while (my $f = readdir $d) {
  $f = "WEB/$f";
  next unless -f $f;
  ++$i;

  next unless $f =~ /.([^.]+)$/;
  my $ext = lc $1;
  my $mime_type = $mimetypes->mimeTypeOf($ext);
  my $path = $f;

  if ('text/html' eq $mime_type) {
    my ($fh, $filename) = tempfile( "tmimeXXXXXXXX" );
    
    open my $fhtml, '<', $f;
    my $html = join('', <$fhtml>);
    close $fhtml;
    $html =~ s/(href|src)s*=s*"(.*?)"/manipulate_href($1, $2)/ge;
    $html =~ s/(href|src)s*=s*'(.*?)'/manipulate_href($1, $2)/ge;
    $html =~ s/(href|src)s*=s*([^'"][^s>]+)/manipulate_href($1, $2)/ge;
    print $fh $html;
    close $fh;

    $path = $filename;
    push @tempfiles, $path;
  }

  my $part = $msg->attach(
      Type        => $mime_type,
      Path        => $path,
      Filename    => basename $f,
  );
  $part->attr('Content-Location' => 'http://example.com/' . basename $f);  
}
closedir $d;

$msg->print(*STDOUT);

unlink $_ for (@tempfiles);

sub manipulate_href {
  my ($attr, $target) = @_;

  return qq{$attr="$target"} if ($target =~ /^http:///i);
  return qq{$attr="http://example.com/$target"};
}

The two important things here are the fact that each element must contain the Content-Location header (ok, is somewhat of an oversimplifaction, because there are other ways to identify subcontent, but this is the easiest) and all URLs must be absolute! This is why there is all the regex replacement going on (again, this is quick hack, if you want to create production code, you should consider using a parser. An other possibility – which I haven’t tried – is to use the BASE tag – you may also want to check out the changes IE7 brings to it, although most probably they wouldn’t affect you).

Now, with the MHT file created, time to try it out (with IE obviously):

mhtml:http://ghdb.mirror.googlepages.com/ghdb.mht!http://example.com/_0toc.html

The result is an IE consuming 100% CPU (or less if you are on a multi-core system :-)) and seemingly doing nothing. Tried this on two different systems with IE6 and IE7. Now I assume that in the background it is downloading and parsing the file, but I just got bored with waiting. Update: I did manage to get it working after a fair amount of working, however it seemed to want to download the entire file at each click, making this solution unusable. It still might be an alternative for smaller files…

Conclusions, future work:

• Both solutions want to download the entire file before displaying it, making the solutions very slow in case of large files.
• It would be interesting to see if the MHT could incorporate some compressed resources. IE, something like: Content-Encoding: gzip, base64 (first gzipped, and after it base64 encoded). This could possibly reduce the size problem.
• It would also be interesting to know in which context the content is interpreted. Hopefully in the context of the MHT file URL (ie, in this case http://ghdb.mirror.googlepages.com/), rather than the specified URL (ie. http://example.com), because, if not, it can result in some nasty XSS-type scenarios (ie. malicious individual crafts MHT pages with resources being referred to as http://powned.com/ and hosts it on its own server. Convinces a user to click on the link mhtml:http://evil.com/pown.mht!http://powned.com/foo.html and steals the cookies for example from powned.com, even if powned has no vulnerabilities per se!). I’m too lazy to try this out :-), but hupefully this can’t happen.

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="">
    </frameset>
</html>

First of all you would say: but frames are so 1998! And you would be right. Frames are outmoded, deprecated and a usability nightmare (because you can’t bookmark the exact state of the frameset), you have to use them in certain situations. Like, for example when providing a "unified menu" in an intranet where you can’t (or don’t want to) touch all the sub-sites referenced. "The right tool for the right job".

Back to our problem: the page from the upper frame contained a bunch of links targeted at the lower frame in the form of:

<a href="http://www.example.com" target="work_frame">Example</a>

The problem was that while on all "sane" browsers the link opened in the lower frame, Internet Explorer (both version 6 and 7) insisted on opening a new window for the link. Finally I got the idea to create a blank page and set the lower pane to it:

<html>
    <frameset rows="20,*" border="0" frameborder="no">
        <frame name="menu" src="menu_frame.html" scrolling="no" noresize="1">
        <frame name="work_frame" src="blank.html">
    </frameset>
</html>

Magically everything worked. So there you go: IE + Frames = Headache (from banging your head against the desk), or at least Magic.

PS. I never tried using "about:blank" instead of an explicit blank page, which seems to be standard (I don’t know if official or unofficial) between the major browsers. Possibly it would also work (and has the advantage that you don’t have to explicitly code an "empty" html file).

The post I’m talking about is Is Firefox less secure than IE 7?. First a little disclaimer: I may be biased in this matter (but who isn’t) as someone who’s been using and loving FireFox since version 0.9. The sentence I have the most issue with is the following: Firefox alone in recent months has had more exploits than Windows XP and Vista combined (yes, I should complain to George Ou for this one, and be sure that I will). People please try to limit ourselves to useful and meaningful information instead of trying to construct bogus and meaningless statistics to prove our points. If we have biases, lets come out and share them (like I did earlier) and lets try to compare apples to apples and oranges to oranges. This quote was insulting to the intellect of your readers (who are smart enough to realize that within MS there are different teams working on different products and they are so separated that you could almost call them a company withing a company). It is as if I would say that: IE had more vulnerabilities than there were full moons in 2006, so it is bad.

To finish up with an other statistic (again biased, but at least it is clear from the context): during 2006 Internet Explorer was vulnerable for 286 without a patch being available (78%) and Firefox for 9 (2.5%)

• In Firefox you can use the View Source Chart extension to view the source after the javascript has executed. There is also the versatile Firebug, but IMHO that’s an overkill for this.
• For Internet Explorer there is the Internet Explorer Developer Toolbar which is free (as in beer) and as of writing this required no WGA silliness.
• And the bonus tips: if you are using Firefox, it may be worth to install the User Agent Switcher plugin and to switch to IE, because exploit sites were known for trying to serve up different exploits for different browsers. If you encounter scripts of type JScript.encoded or VBScript.encoded, you should find this tool useful.

Warning! These methods actually execute the script on your machine! They should be used with extreme care, and preferably only in controlled virtual machines or computers not connected to network.

1. Yellow fading effect on web pages
2. Downloading and running an executable in Internet Explorer if you have your Internet Zone security level set to low.

My version consists of two parts: a style using the underscore hack to make the contents of the tag italic for the security conscious users (those who don’t have Javascript enabled) and then a script written in unobtrusive style which (a) adds a " before and after each tag and (b) disables the italic style. You can find the sources below.