Now that this paper is officially public, the full story of CSS-based cross-origin theft can come out. (As an aside I'd like to note that I contributed little other than review to the paper so credit must go to the other named individuals).
For background reading, see my Dec 2009 original post and an update that notes Firefox fixing the issue.
In the original post, I state two mitigating factors that prevent the attack being very serious: the fact that quotes and particularly newlines stop the attack from working due to the way CSS parsing is specified.
It turns out that Internet Explorer is not compliant in either of these aspects, leaving it more vulnerable that the other browsers. Not only is it the most vulnerable, but it is also the only browser to not have a fix available for its latest stable version. Fully patched IE8 is still vulnerable.
For an example of how easily data can be stolen cross-origin, try this demo in IE:
It uses the font-family CSS property to steal all text from the injection point up to the next ; character. Alternatively, to get more control, we can use background-image:url( which will steal all text from the injection point up to the next ); sequence (which can be useful as it is less likely to occur by 'accident').
I have PoCs which will steal your webmail's XSRF token, with follow-on loss of account integrity and confidentiality. It's a nasty attack: e-mail someone a link and if they click it, they are owned with a pure browser cross-origin bug. I don't think it would be productive to share any PoCs at this time.
Talking to some greyhats, I was surprised to learn this bug has been public since at least 2008. If you speak Japanese, see:
That's a dangerously long time for such a bug to be live and known by hackers.
Browsers are complicated pieces of software and will always have bugs. Time-to-fix therefore matters for a browser. If security is a factor in your browser choice, I recommend you look at Opera or Chrome. These browsers fixed this bug the fastest.
When you write that "Internet Explorer is not compliant in either of these aspects", does this mean that IE will parse:
as a CSS string even though it contains a line break, as well as:
as a CSS string even though ' is escaped?
"If security is a factor in your browser choice, I recommend you look at Opera or Chrome. These browsers fixed this bug the fastest."
One, determining overall browser security on how well it responded to one bug is pretty stupid. Two, in Chrome's case you also reported it to your employer first. So there shouldn't be any surprise that it was among the first to get fixed. It's also interesting that when this was an active bug in Chrome you sought to keep it as quiet as possible, but now are happy to make IE's issue public. I hope MS returns the favor, but I doubt they'd sacrifice people's security that way.
@Anonymous: unfortunately, I must disagree with your comments and make a few corrections:
1) This IE bug has been public since at least 2008. Any story you may read which uses the term "zero day" is misusing that term. See e.g. http://d.hatena.ne.jp/ofk/20081111/1226407593
2) Opera and Chrome being fast to respond to security bugs is a pattern you will see repeated. It is not just this one bug.
3) The bug was kept "quiet" until a good plan was developed to fix it. It is hard to fix this bug without breaking website compatibility. Once a good fix had been designed, it was shared with all major web browsers at the same time.
4) I've been told by several greyhats that they were very aware of this IE bug. Maybe they already pwned you. Don't tell me I'm putting users at risk by trying to get it fixed. What puts users at risk is when a publicly disclosed vulnerability is left unaddressed for two years.
Post a Comment