Cenzic 232 Patent
Paid Advertising
web application security lab

Microsoft Script Accenting

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!

7 Responses to “Microsoft Script Accenting”

  1. fidels Says:

    Oh my, XOR’ing scripts and names using a single, static key is definately NOT a good idea! Of course, a bruteforce attack would take a while, but there would be no need for one: you can use simple frequency analysis to beat XOR encryption in no time, especially if you know that you are looking for names and strings commonly found in webpages…

    As Wikipedia says: “By itself, using a constant repeating key, a simple XOR cipher can trivially be broken using frequency analysis. “

  2. RSnake Says:

    Fidels - just to be clear, you won’t actually “see” the data (or you shouldn’t be able to anyway) it would just appear in the other domain as garbage. We are hoping that said garbage doesn’t translate into something non-garbage and unexpected, but really that’s pretty unlikely. If you could see the data, then it wouldn’t even take static analysis, you’d just look at what it turned into and XOR each char 256 times until you ended up with your original char (worst case) or use a lookup table and you’d be done with it.

  3. fidels Says:

    Well, what I meant was that you can’t really be sure that the data will remain hidden (there’s always a bug somewhere, waiting to be found and exploited), so you should probably put some effort in the encryption mechanism to make things more complicated for the attacker that eventually gets the chance to take a look at it…

    I’m not saying that one should blowfish everything, because that would take a huge amount of resources and may introduce the “unexpected” stuff you don’t want to get. But using a slightly more complicated encryption algorithm (variable-key XOR, Vigniere cipher, Enigma or the like) might make things a lot more difficult for the eventual attacker (although not for the determined one).

    All in all, I think it’d be a small price to pay for quite a bit of added strength, but that’s just my view of it, and I’m an absolute ignorant in all these things, so don’t mind me :P

  4. fidels Says:

    Oh, and by the way, I mentioned frequency analysis because it can probably decrypt the data in a single pass, and that’s as easy as it gets :D

  5. Ronald Says:

    Depening on what “string” to crack, length isn’t an issue nor is mixed alphanumeric. Today’s strongest passwords are passphrases like:

    iseealittleduckyintheriveranditlookscute

    Tough nut to crack and easy to remember, LOphtCrack can find a windows pass in seconds in any alphanumeric order, it has more trouble with passphrases tough. :)

  6. Ronald Says:

    @fidels who said:

    I’m not saying that one should blowfish everything, because that would take a huge amount of resources and may introduce the “unexpected” stuff you don’t want to get.

    === Depends, Blowfish isn’t that useful, your best bet would be AES Rijndael these days, and performance isn’t an issue. The biggest issue is still key management, where you keep the keys? yes… :)

    @fidels who said:

    …But using a slightly more complicated encryption algorithm (variable-key XOR, Vigniere cipher, Enigma or the like) might make things a lot more difficult for the eventual attacker

    === *cough* that can be analysed with pencil and paper. ;)

  7. fidels Says:

    @Ronald

    Sure it can, but there’s less people that know how to do so: let’s face it, most of the so-called hackers out there don’t know a thing about cryptography, and tend to rely solely on pre-made programs. Make it a bit difficult for them and many will be discouraged… at least until new programs start to appear, and then you slightly change your algorithm…

    Btw, if you really want to be safe, you should keep the keys in your pocket :-P