^{March 7, 1997.}
Microsoft: A case study in bad software design.

        In this article, I will examine the recently-discovered security problem with Microsoft Internet Explorer. It will illuminate several areas of poor design and sloppiness on the part of Microsoft.

THE FLAW: The bug, which came to light on 3 March, allows remote users to bypass Explorer's security mechanisms and run any program installed on the victim's PC. Worse, you can transparently download any file to the victim's PC and execute it without the victim being warned.

        STEP 1: DEPLOY THE ATTACKER. The first step in the exploitation procedure is to upload the file you want executed. There were various interesting and baroque methods presented for doing that, but by far the simplest is to do this: Make an executable -- for the sake of illustration, let's make it a batch file called badboy.bat. In your HTML code, insert the following tag: <IMG SRC="badboy.bat" HEIGHT=24 WIDTH=22>. This causes the file to be downloaded without the user being asked for confirmation. "But wait," you say. "All that happens is that you get in inline image." True. However, badboy.bat is now sitting safely on the victim's hard disk, in the Internet Explorer cache. Note that the user will see a peculiar icon indicating an error with the image. No problem; simply modify the tag: <IMG SRC="badboy.bat" HEIGHT=1 WIDTH=1> With the tiny width and height, Internet Explorer makes no attempt to render the image. It's utterly invisible.

        STEP 2: ATTACK. Next, you need to invoke the attacking program. Internet Explorer organizes its cache as files in subdirectories. While the location is configurable, the vast majority of people accept the default, C:\WINDOWS\Temporary Internet Files. There are a number of subdirectories called Cache1, Cache2, etc. My tests showed that badboy.bat always wound up in Cache2; I suspect incoming files are hashed based on name and placed in the appropriate cache directory. You can experiment to confirm this. Put a link in your HTML file like this: Here's a <A HREF="doit.url">groovy demo!</A> When the victim clicks on "groovy demo", he/she invokes "doit.url", which is a file that looks something like this: (Not exactly; I'm at home and going from memory.) [Internet Shortcut] file:c:\windows\temporary internet files\cache2\badboy.bat By default, "url" files are executed without question. This loads a local file. Normally, IE warns about the execution of ".bat" files, but since this is a local file, IE "knows" that it's safe, and happily executes it. Bingo.

        ANALYSIS: This problem is easily fixable - in fact, it can be worked around by changing some registry settings. However, the fact that it occurred in the first place illuminates some very poor aspects of Microsoft software:

BAD DESIGN 1 -- Quiet error-handling. If Internet Explorer complained about invalid images, BADBOY.BAT would not slip by unnoticed. Furthermore, it should always provide an indication of an inline image, even if it's only 1x1 pixel.

BAD DESIGN 2 -- Caching policy. Internet Explorer should never cache items with the original file name. It should generate arbitrary names and maintain an in-memory map. That way, even if attackers successfully download code, it's much harder to find the code to execute.

BAD DESIGN 3 -- File names are special. The encoding of "executable" status in file names (e.g. .EXE, .COM, .BAT) is very bad news. On a Unix system, executable status is maintained in a "out-of-band" area, separate from the filename. To make malicious code executable, the user would have to deliberately set the executable bit. Under Windows, names are magic. MS catches most of the magic names, but as this bug shows, it missed a few. (.URL, .LNK under Win95).

BAD DESIGN 4 -- Local files are trusted. Internet Explorer does not perform the usual security checks when asked to execute local files. Microsoft didn't realize that those "local" files may have been "remote" just seconds earlier.

BAD DESIGN 5 -- Complexity is hidden. At first glance, Windows 95 and Windows NT seem much simpler than UNIX, because they are superficially easier to use. However, they are in fact more complicated than UNIX (compare the API's, for example) and this complication is hidden from the casual user. It took quite a bit of playing around for me to understand registry settings; the Windows on-line documentation is useless. Once can validly criticize UNIX for overwhelming the beginner, but at lease UNIX online information is accurate and complete. Because so much of Windows is hidden from the user, you can never be sure you've plugged all the holes.

BAD DESIGN 6 -- Impression of security. Microsoft has spent much to leave the impression that IE and ActiveX are secure. A recent article by Bob Atkinson in the comp.risks newsgroup illustrated the impressive and dramatic measures Microsoft took to ensure the integrity of digitally-signed code fragments. However, what Microsoft fails to realize is that when the very foundation is insecure, there's no point in piling layers of security on top. Microsoft's security strategy is like the Maginot line: Impressive in theory, but trivial to circumvent in practice. You just go around it rather than through it.


Originally appeared in alt.destroy.microsoft. Used with permission. GeoCities Free Home Pages.