Late last week, a security flaw in Internet Explorer 8 was publicly disclosed to the Full Disclosure mailing list. The flaw allows attackers to steal private information from online services such as web mail and Twitter, allowing attackers to, for example, delete e-mails or send tweets from their victims' accounts.

The post was made by Google employee Chris Evans. He stated that the reason for going public was to try to persuade Microsoft to fix the problem—the new flaw is a variant on an older attack, and the details of the flaw were made public in a paper authored by Carnegie Mellon students that Evans reviewed. While the other major browser vendors have made fixes to their browsers to prevent attack—Chrome 4.0.249.78, Safari 4.0.5, and most recently Firefox 3.6.7 and 3.5.11 all include protection against the flaw—Microsoft has thus far failed to update Internet Explorer to provide protection.

The attack compromises the same-origin policy. The same-origin policy is designed to prevent scripts from one domain from accessing data belonging to another domain. For example, a script from example.org should not be able to access cookies or page content from twitter.com. These attacks, where one site (controlled by the attacker) compromises the secret data of another site, are called cross-site scripting (XSS) attacks. There are many different ways that a site on one domain can embed content from another domain; images are commonly embedded in this way, as are Flash movies to deliver content from sites like YouTube.

This particular attack uses a different approach to embed: it uses cascading stylesheets (CSS), which are used to control the fonts, colors, and layout of HTML pages. CSS is particularly interesting for this style of attack because of the way in which it is interpreted by the browser. The CSS specification requires browsers to be extremely forgiving of improperly-formed CSS. In part, this is so that future versions of CSS can include new features without breaking page display in browsers that do not support those new features; in part, it's due to Postel's law—the concept that computer programs should be as generous as possible in their interpretation of data they are given.

This fault-tolerant handling of CSS files is what leads to the vulnerability. A malicious page can tell the browser to embed any other page and to try to treat that embedded page as if it were CSS. Most of the time, even with CSS's error-tolerant parsing, this won't achieve anything. HTML pages just look too different from CSS to be successfully parsed as CSS. However, if the embedded page is written in just the right way, it will look sufficiently like CSS to trick the browser into interpreting it as such.

For example, this (deliberately constructed) tweet looks just enough like CSS that, when used as a CSS file, the browser will interpret the page as if it were, in part, CSS.

<style> @import url("http://twitter.com/scarybeaststest/status/22869034262"); </style> CSS lets you load stylesheets from anywhere

This is a problem, because although scripts on the malicious page cannot, in general, read information that has been embedded from other domains, they can programmatically access CSS rules, even if those CSS rules came from CSS files loaded from other domains—and even if those "CSS rules" came from files that were not really CSS at all.

This problem is in general mitigated by the CSS specification. Although it demands that browsers be liberal in their interpretation, there are limits: strings wrapped in double quote marks, for example, should not be able to contain new lines. The end of the line should cause the end of the string. Though this does not eliminate the problem, it does mean that it would require extremely bad luck for the issue to ever manifest itself as a real problem.

The exception, however, is Internet Explorer. Internet Explorer is even more lenient than the CSS specification says it should be. In particular, it will disregard line-breaks embedded in strings, and will instead attempt to parse everything as part of the string. CSS uses such strings for, among other things, font families and URLs. The example tweet, when interpreted as CSS, begins specifying the font family, but rather than including a font name, it just has a double quote mark. This starts a string, causing Internet Explorer to treat everything that follows as part of font's name.

This includes secret information. When signed in to Twitter, every page includes an "authenticity token." This is used to prevent arbitrary sites from making Twitter updates on someone's behalf without their knowledge—every tweet made via the Twitter website must include the correct authenticity token. That should be safe—it's a standard technique for preventing XSS attacks similar to this, and unlike other aspects of Twitter's security, is properly implemented—because the same-origin policy should prevent sites from stealing the authenticity token from Twitter pages.

<HTML ignored by the CSS parser> {} body { font-family:" <HTML treated as if it were part of the font name> This is how Internet Explorer interprets the page as CSS. Everything before the tweet is ignored; everything after becomes part of the font name.

But using this CSS-based XSS attack, any malicious page that embeds this tweet as if it were CSS can read the authenticity token. With that knowledge, it can freely tweet using someone else's credentials. Similar techniques are used to secure web mail systems against XSS attacks, and the same CSS-based techniques can be used to defeat them, too. The paper describes using the method against IMDB, Yahoo! Mail, and Hotmail, and the Full Disclosure post demonstrates the attack against Twitter.

In addition to demonstrating the attack, the paper also describes ways in which it can be guarded against. At its heart, the problem is with how the CSS specification is written; if the specification required stricter handling of CSS files, it would not be possible to steal data in this way. The specification is well-intentioned, as the lenient parsing makes it easier to update CSS to incorporate new features, and sufficiently many sites depend on lenient handling that no browser can afford to be completely strict. An effective trade-off is to use lenient parsing for CSS loaded from the same domain, and stricter parsing—that gives up when an error is encountered, rather than trying to persevere until it comes across anything that looks like CSS—when loading CSS from other domains.

Four of the mainstream browsers—Opera, Safari, Chrome, and Firefox—have been updated to do precisely this. The exception is Internet Explorer 8; it uses lenient CSS parsing rules regardless of the domain used to access a CSS file. This is made especially unfortunate by Internet Explorer's uniquely vulnerable status—because the browser is even more lenient than it ought to be, it's far more vulnerable than the others. It's this combination of a lack of a patch and greater vulnerability that caused Chris Evans to report the flaw publicly.

The Internet Explorer 9 Platform Previews are also vulnerable to the same issue. Though the previews have made great strides in improving their standards compliance, all four previews show the same excessively lenient, nonstandard behavior as Internet Explorer 8. Older versions of the browser are also likely to be affected.

Microsoft has responded that it is investigating the flaw, but no patch is available yet; indeed, the tweet is the only response the company has made. Those curious can check out a simple proof of concept that will demonstrate the issue by posting to Twitter as the currently logged-in user.

This is not the first time that a Google employee has publicly disclosed a Microsoft security flaw; Tavis Ormandy received both criticism and support for his decision to make public a flaw back in June. This situation is a little different, however; this flaw is undoubtedly public, thanks to the Carnegie Mellon paper and the fixes made by other browsers. Evans believes that Microsoft may even have known about the problem as far back as 2008; if true, it makes the lack of response particularly embarrassing.