eWeek reports that there’s another Win2K security vulnerability. This wouldn’t be all that interesting, except that it seems entirely gratuitous: like equipping a car with a bag of glass shards and then reporting, regretfully, that the shards may be used to impale the driver.
The vulnerability? When you preview a file in Win2K, it converts strings that look like email addresses into hyperlinks, so that you can click on them and email the owner of the file. But Windows doesn’t check for dangerous strings when it does this conversion, so when you click on the link you can execute arbitrary code.
Windows is full of these gimmicks. I doubt that anyone really needs to be able to click on every email address, but that’s what they’ve got set up. I’d prefer a trivial loss of convenience (rather than making it clickable, why not just make it selectable?) to a sizable loss of security.
Assuming that we leave the clickable email address in, shouldn’t there be a stronger email-address checker? I’m sure that most bits of Javascript code don’t constitute valid email addresses. Shouldn’t the text-to-mailto converter be stripping out a large number of characters, thereby rendering most bits of code useless?
. . . Wait a second. It’s even worse than I thought. It’s not that the link could execute malicious code as soon as you click on the link; it’s that the code executes as soon as the file comes up in the preview pane. I just don’t understand why this would happen: why would the code inside the link execute automatically? I can see converting text to a link, but why execute the code? This goes beyond mere oversight, into what looks like brazen stupidity.
Update: After talking about it with Seth, it’s — at one level — not all that stupid. I was puzzled why the file-properties pane would ever need to execute any code. The reason — which I didn’t understand — was that the properties pane is basically running an IE control, so it needs to render HTML and Javascript and so forth. Additionally, IE allows URLs beginning with ‘javascript:’ in the background-image CSS property. The third, and I think final, bit is that the IE control was running unsandboxed: whereas code running inside your browser can’t normally do much damage to your machine (like changing or deleting files), the file-properties pane had no such protections.
So it was my misunderstanding, and some rhetorical license, that led me to call it “brazen stupidity.” I’m sorry about that; I should look more closely next time. It’s actually not stupid to need to execute code in that pane; it’s a perfectly reasonable thing to do when that pane is, essentially, a small web browser.
It is strange, on the other hand, that Microsoft didn’t sandbox that chunk; I’m curious whether they designed it with no sandboxing, or whether that was just oversight in the implementation.
Finally, I can’t think of any good reason to allow Javascript code in the background-image property. The CSS2 spec doesn’t disallow Javascript code there — it just says that the value of the background-image property must be either ‘none’, of type ‘URI’, or inherited from the parent — but I can’t think of a good reason to allow code there. It seems smarter just to turn off that ability altogether.