SP2 Flaw Report Falls Short

By Larry Seltzer  |  Posted 2004-08-18 Print this article Print

Opinion: The misguided advisory from Heise Security sets unrealistic expectations for a new Windows security feature and then criticizes Microsoft for not meeting them.

When I first saw the advisory "Flaws in SP2 security features," written by Jürgen Schmidt of Heise Security, I just laughed and blew it off as a big nothing. Now, I agree that it illustrates limitations in one of the new security features of Windows XP Service Pack 2. But a flaw? Thats a hard claim to make. The basic claim of the advisory is that the new file-attachment security features of SP2 have a hole that allows attachments from untrusted sources to be executed in spite of protections Windows claims to provide. What are these protections?

According to Microsofts description of these new capabilities, "Application developers will be able to call the new AES [Attachment Execution Service] dialog box from their Windows applications." It appears that CMD.EXE doesnt do this. This is what Heises Schmidt found.

The AES consists of a single COM interface named IAttachmentExecute. It lets programs do all of the safety tasks, including, I presume, persisting the Zone IDs as the Heise Security advisory mentions. It saves applications from having to do some things they might do on their own.

Note that the quote from Microsoft doesnt say that these capabilities automatically accrue to all Windows programs; they are new capabilities available to the programmer. The idea is that a program can become "safe," as Outlook Express has, by using this facility. Programs that use them automatically get a display of warnings and information about the program, such as its publisher. Other programs arent using them, and users cant trust them as much.

Click here to read about Microsoft pushing back automatic delivery of Windows XP SP2. The heart of the scenario in the advisory is a social engineering attack. The user is told to save the file and run it from a command prompt. The author suggests a message that tells the user to Start-Run "CMD" and drag the attached file to the command window.

This is the part that got me laughing initially, and I still have to laugh. Yes, it does appear that the command shell doesnt use the AES and therefore will execute files that Internet Explorer thinks come from untrusted sources. So? Lets imagine that Windows actually somehow changed all file exchanges to use this facility. Other programs behavior would change and potentially break—and guess who would take the heat for it?

This same scenario, I should point out, works beautifully with non-Microsoft browsers. Theres nothing in Mozilla to stop it. If one more instruction is added to the message, using the chmod command, it works just as well in Linux and Unix, too. Is it a "vulnerability" that users are allowed to run programs?

For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzers Weblog. Just how far are we going to go blaming platforms for social engineering attacks? What do you think of this one?
    From: service@yourcarcompany.com
    To: you
    Subj: vehicle recall

    Our records show that the gas tank in your car model tends to collect dirt deposits. To preserve your vehicle warranty, we recommend that you add a cup of ordinary laundry detergent with each tank of gas.
So, if anyone actually believes this, does it mean that the car is vulnerable to a "detergent attack"? Shouldnt the auto manufacturer have taken steps to prevent this?

The new attachment security in Windows is meant to stop the casual execution of attachments from untrusted sources in the e-mail program where the user encounters them. If the attachments find their way to other environments, such as CMD, theres little Windows can do without seriously getting in the way.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.

Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:   More from Larry Seltzer

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel