Blacklists, whitelists, and security

I had a lengthy discussion with Giorgio Maone (author of the NoScript extension) about what is a security solution and what isn’t. Starting point was my statement that, while being excellent for getting rid of annoyances, neither Adblock Plus nor NoScript are really security solutions. Both have the potential, so why not?

Let’s look at the easier case first: Adblock Plus. Adblock Plus is structured as a blacklist, you usually specify the addresses that you don’t want to load. So if there is a security issue that can be solved by blocking a certain address you will have to add a filter for this address. Requiring an action for each single vulnerability discovered disqualifies Adblock Plus, a real security solution would need to block everything unless explicitly allowed. Right now only the extremely rare case of malware-infested ads would be blocked by default however.

Ok, that isn’t exactly true. I use Adblock Plus to ensure the security of my Thunderbird. My blacklist in Thunderbird has only one filter: “*”. Yes, I block everything unless it is explicitly allowed with an exception rule like “@@|http://img.worsethanfailure.com/*”. So why can’t you do the same in the browser? Because it would make web surfing impossible, unlike a mail client the browser is supposed to connect to numerous different servers. Still, once two new features are in place they will allow you to add some general rules to you list, e.g. “*$object” and “*$script,third-party”. The former will block all objects — those are rarely really needed and you will be able to unblock individual objects temporarily on case-by-case basis. The latter will block all scripts the page loads from third-party servers, those are always a security risk (I wonder whether this will actually break any pages). But until these features are in place and properly documented Adblock Plus isn’t a security solution.

Now to NoScript. I have my doubts whether disabling JavaScript really makes browsing noteworthy more secure if you keep your browser updated (mainly because Gecko developers do such a great job). But this is a different discussion, here it is only important that NoScript’s concept is better for security purposes than that of Adblock Plus — NoScript is a whitelist, it only allows trusted sites to run scripts. So why isn’t it enough? Because a whitelist that can be subverted isn’t worth anything. It is enough to find a single whitelisted site with an XSS (Cross-Site Scripting) vulnerability and suddenly any web site can run JavaScript.

Ok, you need an XSS vulnerability. Is it difficult to find one? In my experience — no. Two weeks ago I looked for XSS vulnerabilities on Yahoo just to prove the point and easily found 8 of them. One (and another one I found later) is still open, and I am sure that hadn’t I reported them all these vulnerabilities would still be open and allow me to run my attacks. Note that Yahoo is one of the more secure sites on NoScript’s default whitelist, the extreme case being bugzilla.mozilla.org that is vulnerable to XSS by design.

All this together means that NoScript will only protect against an attacker who either doesn’t know about NoScript or is too lazy to work around it. Giorgio Maone said that he will remove the default whitelist which is certainly an improvement — but guessing what a user has in his whitelist is still easy (and NoScript users are really forced to whitelist sites). IMO anything that depends on attacker’s ignorance or laziness cannot be called a security solution — sorry, NoScript.

To reiterate the point: it isn’t enough to block by default, you also have to make sure that it is reasonably complicated for an attacker to make an exception apply to him. You don’t see it only in NoScript, Internet Explorer’s zone policies suffer from the same issue — they become worthless the moment you manage to inject your code into some page in the trusted zone. That’s why this model was never implemented in Gecko, it only lulls users into a false sense of security. Even the whitelist in Adblock Plus suffers from this issue if used improperly — that’s one of the reasons I have been so harsh on Filterset.G that uses very general whitelisting making it easy for advertisers to create virtually unblockable ads.

Comments

  • pirlouy

    Once again, nice article…
    I can’t wait anymore for “*$script,third-party” ! :P

    Else, I’m a bit off topic… it seems you’re an expert in security, but if you want to find, you will always find a way to break security. For example spywares can easily add a new extension if they want.

    So it’s a good thing to deal with security, but you can’t fight against users who install a lot of thing…

    I don’t like Noscript because I consider it ruins web pages. But saying Noscript is not secured because of a little detail (an attack against noscript users: 0.01% web-users) is a bit “far-fetched”.

    But I’ve understood your ideas, what you mean. ;)

    Wladimir Palant

    We are speaking about an attack exploiting Firefox vulnerabilities – that’s what NoScript is supposed to protect against. And if somebody is launching this attack, NoScript is certainly more noticeable. Still, so far NoScript has been flying under the radar but this can change. Meaning that while NoScript offers a little protection from attacks that don’t consider it, relying on NoScript would be foolish.

  • Giorgio Maone

    Wladimir, you forgot to mention that I’m actively developing XSS countermeasures.

    I can add that the path I’m following is very promising, and it will probably take care of most, if not all, the web-based attack vectors (email is another story, of course).

    After our nice conversation I realized my first approach involving outgoing traffic analysis was too much “Enumerating Badness”, far from the spirit of NoScript, so I drastically changed direction.

    I won’t enter into technical details right now, but I plan to release a preview build in 36-48 hours at most. Your comments will be welcome as always :)

    Wladimir Palant

    I didn’t forget, it just wasn’t relevant here, and I am still very skeptical of what you are trying to do. You cannot fix the web that easily. XSS is everywhere and you will only be able to block the most obvious kinds of it (at the cost of usability, as usually). But the sites where it really matters (Google, Yahoo & Co.) already get regular audits and chances are that a successful attack against them will not use anything obvious.

  • Giorgio Maone

    Wladimir, being skeptic is your right of course, since you did not see the code and I didn’t disclose the concept yet.

    Let me just clarify that while my solution comes at some usability cost as usual (security x convenience = K), it’s very bearable and occasional, much more than having JavaScript-only links disabled on not-whitelisted sites like any NoScript user has.

    Moreover, and I know it’s a bold statement, I’m quite confident it will block even the less obvious web based XSS, at least in the scope of the NoScript “perceived contract” (i.e. when the “phase 1 vector”, the attack initiator, is an unknown web page).

  • Jeff Wilkinson

    You wrote: “The latter will block all scripts the page loads from third-party servers, those are always a security risk (I wonder whether this will actually break any pages).”

    I have just been researching it so far, not using it on my own sites, but the Yahoo! User Interface Library (YUI) set of very useful and powerful scripts is one that may well be broken by rules this tight.

    For one thing, yahoo is offering to host them, so you can use them but not use your own copies, pointing to theirs instead.

    You can of course put the scripts on your own site, but your suggested rule about now loading 3rd party scripts would break any that took advantage of the yahoo hosting. I’m sure this isn’t the only case of a legitimate use of scripts hosted elsewhere.

    Here’s info:
    Yahoo! User Interface Library (YUI)
    http://developer.yahoo.com/yui/

    Free Hosting of YUI Files from Yahoo!
    http://yuiblog.com/blog/2007/02/22/free-yui-hosting/

    Wladimir Palant

    Using these scripts hosted on Yahoo would be a very bad choice. You make yourself dependent on Yahoo (what happens with your site if Yahoo goes off-line because of some technical problems?), but more importantly – you trust Yahoo with the security of your site. If Yahoo’s servers are hacked these scripts might suddenly start serving malware. We have seen it before (http://www.enterprise-security-today.com/story.xhtml?story_id=28597). And I don’t even want to talk about all the data you inadvertently send you Yahoo. Unfortunately I know that many people will use this offer nevertheless.

    The main question is: will the site still be usable if these scripts fail to load? Judging by the examples I suspect that this isn’t the case. That means that you will either whitelist Yahoo’s scripts or look for another site with a more sane webmaster.

  • Jeff Wilkinson

    yes, I know there are risks to using the scripts from yahoo’s server, and I’m not saying that I would make the choice to use them. At this point I would not, for the reasons you mention. (privacy, security, own control over all my site’s files)

    I’m just saying that at least one very large and generally well-respected javascript library system is offering this kind of thing. If you read the comments on their blog about this hosting, you’ll see that there are many people who seem to think this is a good thing and seem likely to use it.

    Yes, as a user, you could whitelist them, if you are a user who is smart enough to know what is wrong when the site doesn’t work, and how to whitelist. (hopefully adblock or your browser would tell you or give clear indication that something was blocked, and would offer a way to get details and to whitelist them if necessary)

    I can also say that I use smugmug.com for photos. They are using YUI. I don’t know if they’d be using the hosted scripts, but they might. They also use subdomains for each account, so it’d be likely that user.smugmug.com might point to scripts on another subdomain… www.smugmug.com? Just an example.

    Anyway, whether you think it is risky or not, it seems that this is one example of a legitimate 3rd party hosted script use that may become widespread. So, your plans for security rules should consider that.

    Wladimir Palant

    The third-party flag is supposed to disallow loading from a different TLD only. So loading scripts from user.smugmug.com on www.smugmug.com will be fine, only loading scripts from user.hackhack.com will be disallowed. Otherwise this flag would most certainly break every major site out there.

    Anyway, I don’t think the rules I mentioned above will ever be added by default. It will be documented that you can do this, yet the user will still have to add them himself – which qualifies him as above average and probably able to deal with most problems.

  • gv

    How about inline script annoyances? There are scripts which doesn’t match “*$script,third-party” rule – they are inline – and I can’t find way to disable them. It would be nice feature to have, in addition to:

    http://www.badsite.net/*$script

    to have f.e. option “inline”:

    http://www.badsite.net/*$script,inline

    to eliminate inline scripts. Or to dream even more – to have parameter based on content:

    http://www.badsite.net/*$script,inline(*var banner*)

    Thanks.

    Wladimir Palant

    Adblock Plus doesn’t work like this. You will need GreaseMonkey to do something with scripts that are not loaded with additional requests.

  • Ebgem

    You are assuming that all malware distributors are evil geniuses. They are not. The chances of a trojan being written that is advanced enough to get past noscript is much smaller than the chance of one that works on the vanilla install of Firefox. Noscript isn’t perfect security, but it is a very large reduction of the risk.
    Fortunately, up until now there haven’t been many drive-by download exploits in the wild with unprotected Firefox- but as Firefox becomes more popular, the risk will go up. And Noscript will always reduce that risk, a lot.

    Someday you may regret that you didn’t install it.

    Wladimir Palant

    The thing is that Firefox is pretty good at dealing with the stupid malware authors already. So far I have only heard of malware targeting old and already fixed security issues. That leaves us with “evil geniuses” who are capable of finding a serious bug in Firefox but decide to abuse it instead of reporting. And those could easily work around NoScript as an extra bonus.

    Also, as I wrote earlier – Firefox is a much harder target to hit than Internet Explorer, which is why I don’t expect significant security threats any time soon (if the developers keep up with their excellent work of course). In this context I don’t see NoScript reducing anything significantly, but it takes a lot of credit for something that Firefox does out of the box.

  • 123

    multiple layers. though they need more maintenance.

  • Jonny

    He, how are you?
    Just wanted to mention, I tried the 3rd party line in adblock Plus and deactivated NoScript, and it works, so far at least :).
    Since an add on is a potential risk, and only FF uses them what would be your alternative?
    Block JS globally and manually allow each, or is that too time consuming?
    Or use Opera with urlfilter.ini?

    PS: I came here following a link from Lorenzo Celsi’s Blog, he is quite furious about the author of Noscript and bashing everybody who defends using it :D.