Microsoft is investigating a flaw in Internet Explorer 8 that allows attackers …

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.

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.

Hey, maybe next they will increase their distributed computing infrastructure even further by starting their own botnet "as a way to persuade Microsoft to fix security flaws that allow botnets."

This is one guy in a company of 21,000. Let's get real here. He saw a bug and was upset MS wasn't being as prompt as the rest of the industry so he made a mailing list post. I wouldn't take this as anything more than that.

Wait, MS takes 2+ years to fix a pretty simple XSS bug and Google is the bad guy? What am I missing?

My thoughts exactly.

I mean, it's not as though this was a hitherto unknown flaw that will only now (as a result of the mailing list post) be widely exploited. Apparently, prodding Microsoft to fix known flaws in their products is "evil" now, and practically as bad as setting up a botnet. The mind boggles.

Not to shift blame here, but really? I'm sure all the people on the MS Security and IE teams love this guy for screwing over their Labor Day holiday. Would waiting until today have hurt so much?

I doubt that if you were in the position of someone who may have had important information compromised because of this over your labor day weekend, you'd be wanting someone to expose how that could have occurred today simply because it isn't labor day. Then again, I don't know you personally, so I regret that possibly being a misjudgment.

So wait, now Google is the bad guys for mentioning that a publicly known flaw that every other vendor already fixed is still wide open in IE? And it's even worse because the guy that works for Google mentioned it during a HOLIDAY? I seriously doubt the IE team or security team at Microsoft rushed back into work to fix the problem...

How dare he! I mean as long as the flaw isn't publicized it's impossible for other people to discover and use it, right? Oh wait, no it isn't - security by obscurity just doesn't work.

The IE team should get off their asses and fix it asap - after all everyone else already did. That's just not news, the older paper has been available for months. The difference to the Ormandy thing is exactly that: Half a week (or whatever it was back then) may not be enough to fix a serious problem, but several months sure is.

If this really was a variant of a flaw from the end of last year, and Microsoft has not fixed it, I'm not surprised someone has posted the new variant. The fact he's a Google employee does besmirch the Google name a bit for some people, but maybe Google is perfectly OK with this kind of PR (who knows?). I know if a Microsoft employee did this in the reverse the same sorts of mud-slinging would be incurred, so turnabout is fair play.

However, it's pretty important for Microsoft to start fixing these sorts of flaws when they come out, even if they're not reported directly to them by someone. You'd think they'd try to be up on stuff like this, no?

In some cases, user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there. CSS 2.1 reserves for future updates of CSS all property:value combinations and @-keywords that do not contain an identifier beginning with dash or underscore. Implementations must ignore such combinations (other than those introduced by future updates of CSS).

To ensure that new properties and new values for existing properties can be added in the future, user agents are required to obey the following rules when they encounter the following scenarios:

Unknown properties. User agents must ignore a declaration with an unknown property.

Illegal values. User agents must ignore a declaration with an illegal value.

Malformed declarations. User agents must handle unexpected tokens encountered while parsing a declaration by reading until the end of the declaration, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes.

Malformed statements. User agents must handle unexpected tokens encountered while parsing a statement by reading until the end of the statement, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes.

Invalid at-keywords. User agents must ignore an invalid at-keyword together with everything following it, up to the end of the block that contains the invalid at-keyword, or up to and including the next semicolon (;), or up to and including the next block ({...}), whichever comes first.

Unexpected end of style sheet. User agents must close all open constructs (for example: blocks, parentheses, brackets, rules, strings, and comments) at the end of the style sheet.Unexpected end of string. User agents must close strings upon reaching the end of a line, but then drop the construct (declaration or rule) in which the string was found. (PL: IE doesn't do this)

is this where the "speed" of ie8 is coming from, cutting corners like this? I don't know enough about it to assume, but ms has been doing plenty of competitive promo on performance/security lately, would be a shame to find more of the same finagling that got them where they are now.

How dare he! I mean as long as the flaw isn't publicized it's impossible for other people to discover and use it, right? Oh wait, no it isn't - security by obscurity just doesn't work.

The IE team should get off their asses and fix it asap - after all everyone else already did. That's just not news, the older paper has been available for months. The difference to the Ormandy thing is exactly that: Half a week (or whatever it was back then) may not be enough to fix a serious problem, but several months sure is.

FF 3.6.7 was released on July 20th so it's really not that long time ago. I am not trying to protect Microsoft here, they should do better job, but I think he caused more harm by raising the issue this way.

Microsoft just seems so oddly inconsistent.I read articles about all the good work and good intentions the developers have developing IE9, and I think maybe there's hope, maybe there's people working there that actually "get it".Then things like this get brought out... barely a murmur from them, and they might have known since 2008?? WTF?Is it just completely different groups, or are they really that schizo?

Hey Google, why don't you post more details of the the kernel exploits you patched in Chrome last week? Oh I forgot that Google is not as transparent as companies like MS. When Google is an open book about the flaws it its software I will actually respect what they are doing.

"...Evans believes that Microsoft MAY even have known about the problem as far back as 2008"

Why do you all seem to easily pick out the 2008 but fail to see the "may" in that sentence? This is plain simple english, so it stands to reason that if you must comment then you should have read and fully understood the article. Yes, it's possible they've known since then, but until proven true the statement is as good as false, especially coming from the guy who posted the exploit code (covering his own a$5?).

Unless of course most of you are just commenting for the sake of it. Such shame.

I really don't understand all of the Google hate lately. MS has sat on its ass for two years ignoring this bug while everyone else took care of it. They are the only people who deserve any blame here.

Even if they have known for two or more years, that doesn't make the bug trivial to fix (and Firefox only patching for it in July suggests such). What they're doing here is changing documented CSS handling rules; no small task, especially when backwards compatibility is such a huge goal of theirs. I don't think the researcher in question is at fault here, but don't beat up on MS a ton either. They do a metric ton of regression testing with all of their patches, and often times they will not release a patch until they're sure it will not break compatibility in the Enterprise space.

FF 3.6.7 was released on July 20th so it's really not that long time ago. I am not trying to protect Microsoft here, they should do better job, but I think he caused more harm by raising the issue this way.

Maybe we've got different definitions of "not that long ago", but 1 1/2 months on a security flaw that compromises private data, in my opinion is damn long. And since I think we can assume that Mozilla didn't find out about that bug much earlier than MS, it just means that MS has ignored a critical security flaw for at least 1 1/2months longer than the competition.

Even if that bug is complicated to fix (maybe the IE architecture makes it harder than the FF one, who knows?), that's just not a reasonable timespan..

FF 3.6.7 was released on July 20th so it's really not that long time ago. I am not trying to protect Microsoft here, they should do better job, but I think he caused more harm by raising the issue this way.

Maybe we've got different definitions of "not that long ago", but 1 1/2 months on a security flaw that compromises private data, in my opinion is damn long. And since I think we can assume that Mozilla didn't find out about that bug much earlier than MS, it just means that MS has ignored a critical security flaw for at least 1 1/2months longer than the competition.

Even if that bug is complicated to fix (maybe the IE architecture makes it harder than the FF one, who knows?), that's just not a reasonable timespan..

non-critical patch cycle is 30 days for most of Microsoft products and most larger organizations. So far nobody said this is critical patch. Yes, Microsoft should patch this soon. But look around, fruit company leaves known holes in the system for 6+ months and nobody cares.

announcing security holes the way this guy did is in my opinion not productive especially when he did it on Friday 3pm before 3 day weekend

non-critical patch cycle is 30 days for most of Microsoft products and most larger organizations. So far nobody said this is critical patch. Yes, Microsoft should patch this soon. But look around, fruit company leaves known holes in the system for 6+ months and nobody cares.

announcing security holes the way this guy did is in my opinion not productive especially when he did it on Friday 3pm before 3 day weekend

No, we DO NOT start with "hey but look others aren't any better!" - that's always a horrible excuse, but especially in security matters. Also Safari is already fixed.

And as what exactly do you categorize XSS exploits if not "critical"? Ok posting stuff on others twitter accounts is rather harmless, but authenticity tokens are used on other sites as well. Doesn't look that harmless to me.

PS: And for all those US centric people out there.. for 95% of the world population monday was just a day as every other. Do you know all european holidays by heart? Not that it really matters after months..

PS: And for all those US centric people out there.. for 95% of the world population monday was just a day as every other. Do you know all european holidays by heart? Not that it really matters after months..

To be fair, the guy who released the exploit is an American in America.

I wonder when the Carnegie-Mellon paper was published (it doesn't seem clear from browsing)? The article gives and excellent break-down of the attack itself; but it seems many of the comments are focused on perceived timelines.

I can't find any exact dates beyond build dates of the other browser's patches. So, is this a 1.5 month old problem, or a 2 year-old problem. The former seems a bit long for a vulnerability such as this. The latter is absolutely inexcusable.

Unlike just about every other consumer product in the entire universe, people who make software are allowed to sell products that explicitly disavow any kind of warranty and demand complete freedom from liability for consequential damages from the product. The generally disgraceful overall state of computer security has this as its root cause. We are conditioned to have the perverse expectation that the software we use will be full of unpatched security holes, and then we point fingers of blame at the individuals who dare to point out that the emperor is not wearing any clothes.

Under sane public policies and laws, only nonprofit providers of free open source software would be granted such broad legal immunity. Microsoft, Adobe, Apple, and the rest, should all be legally liable for the consequential damages suffered by users as a result of security flaws in their commercial products.

PS: And for all those US centric people out there.. for 95% of the world population monday was just a day as every other. Do you know all european holidays by heart? Not that it really matters after months..

ehm, I am not US centric. Google and Microsoft are US based companies, he knew on Friday at 3pm exactly what he is doing. I know holidays of all countries of co-workers I work with especially when it's Friday afternoon and Monday holiday.

if he wanted to do as less harm as possible, then he would not release it at the date he did, that was the worst date. If he would really care about fixing and not his publicity, then perhaps Tuesday at 10am would work better.