Windows Animated Cursors Exploit

A recent Slashdot article warning MS Windows (C) users about the latest security hole certainly sparked my interest. Well, not the article specifically, but the replies. I understand that Microsoft have invested some time in sand-boxing IE7 in their latest OS ["Vista"], but the number of users -and we are talking slashdot readers here, not Aunt Tillie's- whose undying faith in the techniques Microsoft have used in Vista, is deeply scaring me. I left it quite a while before posting a comment, but you can read the original here. It's worth a read even if you're not a techie, because it will help you to get past the marketing drivel and understand: you are not safe, no matter how much a closed-source vendor such as Microsoft tell you. You can never be sure unless you've checked every possibility, and this is not possible without the source. For those of you who think this works in favour of windows, remember: Microsoft have had the source for their animated cursor system for over ten years. That they can sell a system to a commercial customer without rigorously checking the source is disgusting.

Quoting another poster before explaining why this exploit bypasses the security features in the latest [and all] MS-operating system:

"You can't stop vulnerabilities"

You sure can. Especially the simple buffer overflow stuff like this. Arguments about protected IE7 aren't relevant, because it's not IE7 that handles the animated cursor [it only loads it]. Only browsers that don't load animated cursors by default fix the problem. Further, the point that this is arbitrary code execution means that the code runs with full ring-4 privileges [unless this exploit runs on Alpha too, then I'm not sure what happens, although you were specifically referring to Vista which doesn't], which is the same level that system services run in. So really, you can't mitigate the effect much at all. I'm no expert on the ring-0 processes in Windows or the glue that binds them to the rest of the system, but I imagine there's some things an exploit of this kind can do [such as accessing your TCP/IP stack and file system] and things it can't [such as making Windows use a new TCP/IP stack of the cracker's creation- but if you've got the privileges above, why bother?]. So now that we've gotten rid of the "this is not really MS fault" suggestion and removed your false sense of security in "protected" mode, where does that leave us?

I only really know hardware enough to talk well about it, but it's the hardware that defines what the software can do. I know fairly well what arbitrary code execution can do on x86 hardware. I'm not blaming x86 for this, it is clearly not that difficult to avoid exploits of this sort on x86 hardware, OpenBSD is the poster child for that kind of safety, but any modern Unix, including Linux, does this quite well.

[I should note that I am not a security adviser of any sort, and this information is based on my understanding of the software and hardware in question, which is not complete. I do not have and I have not viewed the source of any of the Microsoft Windows components, and so cannot ensure the accuracy of this information. I do hope, however, that you take this information into account and ask more questions of those involved when considering the security of any computer software.]

Back to top