Boo Hoo Hoo for Victims of XP SP2

By Larry Seltzer  |  Posted 2004-07-19 Email Print this article Print
 
 
 
 
 
 
 

WEBINAR: Event Date: Tues, December 5, 2017 at 1:00 p.m. ET/10:00 a.m. PT

How Real-World Numbers Make the Case for SSDs in the Data Center REGISTER >

Opinion: Quite a few applications will break under the new security-focused service pack. Many shouldn't have been written that way, and developers have had plenty of warning that things would change.

If you've ever wondered why major software releases such as new operating systems take so long, one of the biggest contributing factors is backward compatibility. Microsoft is especially sensitive to this, and especially with its largest customers. It works very hard not to break old applications.

But with Windows XP Service Pack 2 (SP2), expected to be finalized in the next month, the standard has changed somewhat. The big point about XP SP2 is security, and toward that end, application compatibility must suffer. Some ISVs and other developers are mad. Others not only aren't mad, they see it as a good sign.

Russ Cooper, senior scientist at TruSecure and moderator of the respected NTBugTraq Security mailing list, goes so far as to say, "I hope it breaks more things than it's already broken."

For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzer's Weblog.

If you look carefully at Microsoft's guide to Windows XP SP2 for developers, you can see that the things it bans are generally things developers shouldn't be doing anyway, such as automated download prompts and files with extensions that don't match their content-type value. This is the point that Cooper is making.

Many vendors have already slipstreamed in upgrades to applications to comply with SP2. According to testers in Microsoft's Application Compatibility Support newsgroup, for example, Symantec PCAnywhere works from version 10.5.1 up, including the 11.x versions.

Problems in the debugger in Borland's Delphi in Release Candidate 1 were fixed quickly, although another tester reports that multiple applications under SP2 cannot access the Borland Database Engine.

And like all bug databases, problem reports on XP SP2 have a large share of inaccuracy and overstatement. There were, for example, reports that Apple's iTunes for Windows 4.6 worked if present on a system onto which SP2 was installed, but would not install afresh on an SP2 system.

I tested this myself and had no trouble installing it on an SP2 system. It's entirely possible that iTunes does fail on some SP2 systems, or perhaps the problems observed had nothing to do with SP2. We'll know a lot more after the service pack goes final.

And some ISVs are publicly complaining about the problems. RealNetworks, for example, says, "The changes Microsoft is proposing for SP2 will have serious negative consequences on the consumer experience of many applications and Web sites." Of course, it's not surprising to hear Real complain about Microsoft, nor is it always a meaningful or accurate complaint.

Next page: The real problems. Of course, there are real problems, and I've been a victim of one of them myself. A Web-based application I use regularly breaks under Windows XP SP2. The developers haven't figured out the exact problem yet—I don't have the source, so it would be difficult for me to figure out the problem—but I wouldn't be at all surprised to find out that what it was choking on was something the developer really didn't want to do, like overflowing a buffer.

Users of SP2 get a lot of warnings, especially early on in using it, when they try to run programs that break policy. Rarely are you actually prevented from doing anything, just warned and asked to make a conscious decision to engage in activity that could be insecure.

Microsoft has developed extensive tools for managing the deployment and management of SP2 on a managed network, and I agree with TruSecure's Cooper that enterprises will likely use these tools to roll SP2 out in a relatively crippled state.

Consider this paper on managing the Windows firewall on a network. They can then turn on features as they are more thoroughly tested, or turn them off if they cause problems in the real-world deployment.

For all the whining Microsoft is getting now, there's no serious argument to make that these changes aren't necessary. The next year or so will be a busy one for Microsoft support, but things will get better thereafter.

And a willingness on Microsoft's part to break these old, dangerous applications is more important than just cleaning up an existing mess. It's also a break with the past and with Microsoft's enthusiasm for letting developers make programs that do whatever they want. Security means that programs need to have bounds, and those bounds need to be enforced. It must be a scary thing for Microsoft, but it's an important moment, and they need to move on with it.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

Check out eWEEK.com's 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...
























 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date