This site graciously hosted
by our friends at

Analysis of Topical Vulnerabilities

19 June 2003

We find a point or two of special interest in the "script injection" (see vulnerability in recent versions of Internet Explorer.

(NOTE: The vulnerability was first discovered and reported by GreyMagic Security ( and further analyzed and reported on Security Tracker ( We encourage you to read both the report on Security Tracker as well as the original advisory at GreyMagic (


Let's look at some code, as quoted in the GreyMagic advisory:
What catches our eye first is the mixture of symbolic entities with small integers. It summons up memories of countless lost nights. First in assembler, then Pascal and C, and even in PERL and beyond, we have struggled bleary-eyed to adjust the indices into character strings forward and backward to point with surety to one sub-token or other. That experience has taught us that almost any character-bashing effort that involves small integers is doomed to unsecurity. Why? Because the use of such numbers is a tip-off that the programmer (including ourselves) is working off a casual pre-parse of the string based on a body of experience, not a careful specification. And whenever we try that, we seem almost invariably to miss some diabolical case we've never encountered (like a field that's usually supplied, but in fact is optional).

The next few lines are worthy of comment, too.
A fair try at screening out forbidden characters--and a great example of why, in chapter 4, we recommend that software authors try hard not to write their own code to make such a check. This is an area for specialists, we argue. (And we don't, by the way, represent ourselves as the authorities on this subtle and oh-so-frustrating matter.) If you're not sure you agree, please see for a great discussion about some of the subtleties for checking UTF-8 and Unicode strings for potential security problems.

So there are some code implementation problems that should be addressed. But we feel that there's a bigger issue here.

This vulnerability wouldn't have much punch were it not for the fact that the exploit code gets executed in the "Local Computer Zone". The damage that can be wreaked in such a way is very serious. What opens this door?

First, of course this code trusts user-supplied input.

In Chapter 4 of Secure Coding, we state, "Don't trust web URLs". Since a URL is in essence a user-provided command line, it should be thoroughly scrutinized to ensure that it conforms to the design intent of what should be in the URL fields.

But beyond that--isn't this just the sort of state tampering that the Web's URL/CGI architecture facilitates?

Similarly, embedded HTML fields and other storage that can be modified while on the end-user's browser, must not be trusted and must be scrubbed thoroughly before you act on its contents.

Finally, we'll just make the point again that if your design is such that your code will make use of user input, you should, if possible, suspend whatever privileges or special access not needed at the moment while executing anything based on the scrubbed input. Some operating systems make this easier than others; it may be possible to temporarily suspend a privilege, or to accomplish the same net effect in other ways, such as compartmentalization, as we describe in Chapter 3 of Secure Coding. (For an elegant example of how to use compartmentalization, see Wietse Venema's Postfix mailer --

Since, in this case, the user input can come from an external source (e.g., the Internet), and since the error handling gets acted upon in the "Local Computer Zone", it is in essence crossing a privilege boundary. This could well be indicative of a design flaw that could result in a time consuming and costly remediation process.

Mark G. Graff
Kenneth R. van Wyk
19 June 2003

Copyright (C) 2003, Mark G. Graff and Kenneth R. van Wyk. Permission granted to reproduce and distribute in entirety with credit to authors.

Site Contents Copyright (C) 2002, 2003 Mark G. Graff and Kenneth R. van Wyk. All Rights Reserved.