hackademix.net

Yesterday I published a blind analysis of the so called “Clickjacking protection” included in IE8 RC1. “Blind” because, hype aside, there was no technical documentation available, even if the feature was targeted to web developers who — in order to protect their users — should modify the way their pages are served.

After a while, Microsoft’s David Ross sent me an email confirming that my wild guesses about IE8’s approach, its scope and its limitations were indeed correct. The only information obviously missing from my “prophetic” description was the real name of the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains” HTTP header to be sent before the sensible pages, and today this little mystery has been finally unveiled by Eric Lawrence on the IE Blog:

Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed. If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin.

As I had anticipated, IE8’s “clickjacking protection” is just an alternate scriptless way to perform frame busting, a well known and simple technique to prevent a page from being “framed” in another page and therefore becoming an easy UI Redressing target. Microsoft had to follow its own special path because the traditional JavaScript implementation can be easily circumvented on IE, e.g. by loading the targeted page inside an <IFRAME SECURITY=restricted> element. But the other major browsers are equally “protected” (if we can call “browser protection” something relying on the good will and education of web authors) by “standard” frame busting. Therefore, slogans like “the first browser to counter this type of threat” (James Pratt, Microsoft senior product manager) were marketspeak at its best. Furthermore, this approach is useless against Clickjacking in its original “historical” meaning, i.e. those attacks involving Flash applets and other kinds of plugin embeddings which led Robert “RSnake” Hansen and Jeremiah Grossman to invent the successful buzzword.

However in my post I had also written that having such a scriptless alternative as a cross-browser option would be nice:

I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

David kindly answered

I think this would be fantastic and it’s a great place to start building some bridges.

I agree, in facts I’ve filed an enhancement request for Firefox, and I’m already working to release a NoScript development build featuring X-FRAME-OPTIONS support: that’s relatively easy, since I can hook in the work I’m already doing for the ABE module. (Update 2009-29-01: I just released NoScript 1.8.9.9 development build, featuring full experimental X-FRAME-OPTIONS compatibility support).
It’s worth noticing, though, that this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) “protection” as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

Speaking of NoScript, I’ve got a small but important correction to the otherwise excellent article Robert McMillan wrote for PC World (IDG News) yesterday:

Because clickjacking requires scripting, the attack doesn’t work when NoScript is enabled.

This statement is wrong twice:

1. Clickjacking does not require scripting: JavaScript might make the attacker’s life easier, but it’s not indispensable to throw an attack.
2. NoScript does not need scripting to be disabled in order to protect its users against Clickjacking: its exclusive ClearClick anti-Clickjacking technology works independently from script blocking.

That’s why NoScript can be recommended to anyone, even to grandma who’s not inclined to block JavaScript: albeit I do not encourage using NoScript’s “Allow Scripts Globally” command because the default deny policy is your best first-line defense, many additional protection features such as Anti-XSS filters and ClearClick still remain active even when JavaScript is enabled, providing the safest web experience available in any browser.

Microsoft released Internet Explorer 8 RC1 yesterday with the usual big fanfare, and one of its main marketing punchlines is its “exclusive” clickjacking protection:

Microsoft Adds Clickjacking Protection to IE8 RC1

[…]
One major security update to block Web attacks known as “clickjacking” that the company said makes IE8 the only Web browser to offer such protection.
[…]
The security feature that thwarts clickjacking in IE8 RC1 allows Web-site content owners to put a tag in a page header that will help detect and prevent clickjacking. If a site that uses the IE8 tag detects clickjacking, it will give Web users an error screen letting them know that the content host has chosen not to allow that content, and gives them the option to open the content in a new window that is protected from the attack.
(PC World)

Microsoft IE8 Hits RC1 Milestone, Stops Clickjacking

[…]
RC1 also includes protection against “Clickjacking,” a ploy to get users to click on account buttons while covering the actual site being clicked on using a frame – the first browser available to counter this type of threat, Pratt said.
(PC Magazine)

Microsoft Goes After Clickjacking in IE8

[…]
While offering few technical details of its methods for stopping clickjacking, Microsoft appears to have not only tried to address the browser-based issues, but also sought out the help of Web site owners to make IE8 less vulnerable to the attacks.
[…]
Now, it will remain to be seen whether or not the features offered in the IE8 RC browser have an effect in preventing clickjacking attacks, but you have to give the guys in Redmond credit.
(Security Watch)

Hype aside, forgiving Microsoft’s habit of forgetting precursors of their “first and unique” technologies, what can we infer from the “few technical details”?

At this moment, Tue Jan 27 2009 15:20:49 GMT+0100, searching for Clickjacking on the Microsoft Developer Network I can find just 1 result, i.e. the Internet Explorer 8 Release Candidate Now Available IEBlog’s post, and it doesn’t give away any more juice:

We’ve worked closely with people in the security community to enable consumer-ready clickjacking protection. Sites can now protect themselves and their users from clickjacking attacks “out of the box,” without impacting compatibility or requiring browser add-ons.

Putting all these pieces together, IE8’s clickjacking countermeasure seems to be a “tag” (or a HTTP header, or both) which “web content owners” must attach to the page(s) of theirs to be protected.
So it’s not about users protecting themselves: “Sites can now protect themselves and their users”.
Ooops, we knew sites could already “protect themselves and their users” last week, last year or even one decade ago, and in a more or less browser-independent way too. That’s called frame busting, and it’s done with a simple JavaScript one-liner. Therefore my guess, documentation pending, is that IE8 “invented” scriptless frame busting. All the browser vendors have been discussing something like this even before the Clickjacking bubble, and it’s actually useful because:

1. JavaScript-based frame busting is not always reliable, especially on IE (it works fine in Firefox 3, though).
2. JavaScript-based frame busting does not work, quite obviously, if JavaScript is disabled for whatever reason, unless you’re using NoScript.
3. JavaScript-based frame busting can be easily circumvented on IE by loading the targeted page inside an <IFRAME SECURITY=restricted> element. Ironically, yet another Microsoft non-standard extension to HTML, with security purposes this time, makes IE the only contemporary browser where “standard” frame busting is useless by design.

To sum up, there’s always been a well known and accepted server-side protection option which works everywhere except in IE. As far as we know, the newly proposed anti-Clickjacking tag or header (much like the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes” suggested as fix #1 in Michal Zalewski’s famous “UI Redressing” post and to ABE’s SUBdocument rules) offers an alternate option which, currently, works only in IE8 RC1. Funny how Microsoft can turn a weakness unique to their browser in yet another non-standardized feature to embrace and extend HTTP overnight! :)
But if a web site owner is skilled and careful enough to implement our brand new header (which again, while I’m writing these lines, is apparently undocumented), he will surely deploy the simple and understood JavaScript frame busting one-liner too, and every browser is equally protected.

Furthermore, the press choose the “Clickjacking” buzzword over the proper “UI Redressing” definition, probably to amplify its hype effect. But historically, the term “Clickjacking” has been invented to designate a Flash-based (or more in general embedding-based), not necessarily cross-domain attack. Does this “anti-Clickjacking” feature actually work against the “original” Clickjacking concept? Nothing suggests it does yet, but we’ll see… 2009-01-28 Update: now we for sure know IE8 RC1 offers no protection against plugin-based Clickjacking, as expected.

However, I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

That said, the bad news for IE enthusiasts is that they’ve got no magic “out of the box” protection, despite the press releases I quoted. True, it doesn’t require any “browser add-on” (don’t you love how they managed again to avoid mentioning NoScript?), but it comes with an even more strict requirement: all the sites to be protected must already have adopted a new proprietary hack, i.e. something no end-user can verify, let alone enforce (so long for the “consumer-ready” label).
We’ve been preaching about XSS holes and other web programming errors for years, but developers still fall in the same pitfalls over and over again: if the guys in Redmond really believed that web security could be fixed server-side by just educating web authors, why did they eventually bother adopting those client-side anti-XSS filters which NoScript pioneered?

On the other hand, ClearClick protects you against any type of Clickjacking automatically, as soon as you install the NoScript add-on, with no need for web authors to learn and cooperate. ClearClick keeps working even if you allow JavaScript globally and/or disable all the other NoScript protection features, so you’ve got no excuse to dismiss it. Any reason yet not to switch to safer browsing?

Update

Microsoft’s David Ross sent me an email confirming that my “preemptive” analysis about IE8’s approach, intents and limitations was correct. A blog post by Eric Lawrence is on its way, explaining the technical details as an an “authoritative” source, but I guess the only information still missing is the real name of the header :)
About my stated intention of implementing a compatible feature in NoScript and lobbying Mozilla to do the same, he wrote

I think this would be fantastic and it’s a great place to start building some bridges.

I think so too.

Update 2 (2009-01-28)

Mistery unveiled: the header is “X-FRAME-OPTIONS: DENY” (I still prefer “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes”, but whatever). Now that I’ve got “less blurry details”, NoScript’s compatibility feature is on its way, and I hope Firefox’s is too.

Yesterday and today we’ve got a blizzard of web browser security updates:

• Opera releases version 9.63, fixing 3 remote execution bugs and other security issues.
• Mozilla releases Firefox 3.0.5, fixing 3 remote execution bugs and other security issues.
• Microsoft is about to release an out of band patch for its IE data-binding remote execution vulnerability which escaped the patch pack issued on Tue, Dec 9th.

Microsoft zealots are taking this as an argument to argue that all browsers are equally insecure, and therefore there’s no reason to switch (from IE) for security purposes (an advice which, on the other hand, starts spreading even on mainstream media).
This is quite a debatable statement, if you think about it.
IE’s vulnerability, being a zero day, is actively exploited in the wild by thousands of compromised web sites and puts several millions of users worldwide at risk, while both Firefox’s and Opera’s are still embargoed.
Firefox will be automatically updated for its users before bad guys can analyze and exploit the patched vulnerabilities. That’s effective patching. Opera is in a slightly worse shape, since its update mechanism is not fully automated (it requires user to manually download and install the new version). Microsoft already failed this time, because the vulnerability has been already known and exploited for more than one week.
Right, zero day situations can happen to any software product, and Opera and Firefox might face a similar shitstorm tomorrow. But, even so, there are some interesting differences:

1. Patching policies: Microsoft implements a predictable monthly patching cycle. This is probably good for corporate IT departments, which can carefully plan the so called “black Tuesday” to minimize their troubles, but it’s also good for evildoers and security attention-bitches, who can carefully plan their exploits or disclosures to maximize their impact. Zero day critical vulnerabilities in three different Microsoft products have been disclosed immediately after last “black Tuesday”: is this really a coincidence?
   Firefox and Opera, on the other hand, issue security updates whenever they’re ready and tested.
2. Agility: as everybody knows, Internet Explorer is tightly coupled with the underlying Windows OS platform, and this makes both mitigation and fixing more difficult. In this case, for instance, the suggested work-around required not just hardening the browser itself by blocking scripts and plugins, but also disabling a system-wide data access component (OLEDB): this affected not just surfing the web, with many sites inaccessible or malfunctioning, but also most Windows applications relying upon databases.
3. Viable ad-interim mitigation: even if a browser vulnerability doesn’t involve system-wide components, mitigation until a patch is available almost always requires disabling JavaScript and/or plugin content (the latter is often used to circumvent security features like Vista’s DEP). On IE, such a work-around is hardly acceptable, since “Security Zones”, the mechanism available to selectively change the security level of certain pages, is very obtrusive and almost unusable (yes, way worse than UAC). Opera is friendlier, thanks to its “Site Preferences” which let user quickly change site permissions for JavaScript, Java, Flash and so on. Of course, only a minority of Opera users actually configure a default-deny policy, to selectively allow active content on trusted sites only. However, even those savvy users are suddenly out of luck, if they grant permissions to a site which is vulnerable to XSS: an attacker could circumvent script and plugin blocking by injecting his malicious code there, where it’s allowed to run. But if you use Firefox and you install NoScript, you get a safe default-deny policy configured out of the box and your trusted whitelist is effectively enforced notwithstanding site flaws, thanks to Anti-XSS Protection: JavaScript and other active content will run only where you want it to run.

To summarize: all the browsers can have vulnerabilities and equally need timely patching, but not all the users are equally vulnerable.

Microsoft’s “clarification” on the various workarounds for the recent Internet Explorer security debacle.

Latest updates from Microsoft: the critical remote execution bug which we already talked about affects all IE versions (included IE8 beta) on every supported Windows operating system.
The bulletin also corrects some early assumptions about this unpatched vulnerability, which is being actively exploited in the wild from apparently legitimate sites infected through automated SQL injections:

• The hole is in data binding, and not in XML processing like many (me too) reported initially.
• Increasing the security level of the Internet Zone to “High” and disabling active scripting does not suffice to protect you, even if it makes attacker’s life slightly harder. Not harder than yours, though, since Microsoft’s “Security Zones” have nothing of NoScript’s usability…

The only work-around suggested by Microsoft is disabling both active scripting and the OLEDB32 library, which is unluckily required by most applications working with databases.

So, do you really want to keep inflicting yourself that blue “e”? Or are you ready for a red panda?