1167856 - Client configuration leakage via JS/protocol checking

Status: NEW

(Core :: General, defect)

Description

[Philip Beaman]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150513174244

Steps to reproduce:

By creating an iframe and setting its location to a protocol and then checking on the element it is possible to determine if the client has such a handler configured.

The below code can be used as a PoC:

function testProtocolHandler(el) {
    var ifr = document.createElement("iframe");
    document.body.appendChild(ifr);
    try {
        ifr.contentWindow.location = el;
        console.log(el);
        return true;
    } catch (e) {
        if (e.name == "NS_ERROR_UNKNOWN_PROTOCOL") {
            //No handler
        }
    }
    document.body.removeChild(ifr);
    return false;
}

console.log("Mail client? " + testProtocolHandler("mailto:x"));
console.log("Skype? " + testProtocolHandler("skype:x"));
console.log("Torrent client? " + testProtocolHandler("magnet:x"));
console.log("Control: " + testProtocolHandler("notAHandler:x"));


Actual results:

The code above produces (On my machine):

"mailto:x"
"Mail client? true"
"skype:x"
"Skype? true"
"magnet:x"
"Torrent client? true"
"Control: false"


Expected results:

I do not believe this information should be exposed as it poses a potential security risk. Chrome's solution can be infered from: https://code.google.com/p/chromium/issues/detail?id=451189

I have not been able to confirm if this happens in other Mozilla products, or the mobile version of Firefox.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Pretty sure we have existing bugs about the exception getting thrown in that situation....

Comment 2

[Daniel Veditz [:dveditz]]

bug 484266 mentions the exception, but the main thrust of that bug is suppressing the user-visible error dialog for links which we now do thanks to in-content error pages. But we still throw the exception -- is that why that bug is still open?

We also have bug 167475 to suppress loading these in an iframe, but that doesn't help the fingerprinting because the bug wants an exception for <a href=> and as bug 484266 shows those can be used to generate the exceptions.

Couldn't find a bug explicitly about getting rid of the exceptions. Note that we'd have to also suppress firing the onerror event handlers, or perhaps _start_ firing them in the case when we do find the protocol handler (because we certainly didn't load any contents when you use a mailto: link even if it "works").