Mike sent over an interesting blog post by David Ross pointing to a new paper he and some colleagues at Microsoft wrote about a new concept they call Script Accenting. This is a concept designed to stop a lot of new browser exploits (the type that Michal Zalewski, mikx and http-equiv for those of you who remember those names used to find). While all or most of the known attacks have been fixed there are probably untold left to find and that is what this is intending to fix (not XSS though, for those who are curious).
It’s an interesting concept but being the hacker type the first thing that struck me was this paragraph on how the accent is generated:
XOR-based randomizations are frequently used in security defenses. Our current implementation also uses XOR as the primitive operation for accenting: we generate a 32-bit random number (four-bytes) as the accent key for each domain. The primitive operation to accent a text string is to XOR every 32-bit word in the string with the accent key. When there are one, two or three bytes remaining in the tail of the string, we mask the accent key to the same length, and apply the XOR operation. This accenting operation has two clear advantages: (1) it guarantees that the accented script or any portion of the script is illegible to other domains, regardless of how the script travels; (2) the operation does not increase the length of the script, so the existing browser code can correctly handle the accented script without the possibility of buffer overflow. This is important for the transparency of our mechanism.
Okay, so all we need to do is guess a four byte word, look for some errors and poof, we’re good, right? Well, not so fast, they too have thought of that problem!
Although the above probing attack seems plausible at the first glance, it is not effective for two reasons. First, we observe that scripts in IE are always represented using wide-characters, which means the string “//” is already four-byte long. It requires 256^4 attempts to guess. More fundamentally, even for a browser not using the wide-character representation, the attack still lacks an important prerequisite – there is no way for the attacker frame to detect a syntax error in the victim frame, because the two frames are in different domains. In other words, for the probing attack to succeed, the attacker frame already needs the capability to communicate with the victim frame (e.g., through the onerror method of the victim frame), but such a prerequisite is exactly the domain-isolation violation that the attacker tries to achieve. This is a cyclical cause-and-effect situation. Therefore, the XOR-probing is not a real concern of the accenting mechanism.
I’m not sure I agree with this statement actually. Sure, that’s one way to do it, but generating 256^4 scripts isn’t impossible either (especially if you create and destroy them). Oh, sure, it might take a year, but you can do it. Once they succeed you know it and get the results back and poof, you’re good. Also, In some cases you can actually get data back from other domains (in Firefox at least). Look at the Firefox login checker for instance. While yes, that’s against Firefox only, these bugs tend to happen a lot, and there are countless interesting ways to get at least some amount of data back from other domains through history, the status bar, referers, timing attacks, onload event handlers, etc….
I’m not saying it’s broken, or that the techniques to break it are easy or even possible given current computational boundies, but it feels like the lightweight nature of that is to it’s own detriment, when a longer key might actually solve it in any way that would be computationally possible with modern computing (save turning the Storm worm’s 50MM hacked machines into the largest script accent breaking machine known to man - just before it becomes self aware and kills us all). Breaking a 10 char string is way harder computationally than a 4 char for instance. Perhaps there are more performance concerns though. But for once I don’t see really any major gotchas. It looks like a pretty clean way to solve lots of the browser cross domain hacking issues out there. Sure there will still be vulns, but they’ll have to obey yet another rule. Now, onto XSS!