Is the ASP.Net Bug a Big Deal? MS Thinks So

By Larry Seltzer  |  Posted 2004-10-10 Print this article Print

You might have to wait six months or more to get your "highly critical" browser bugs patched, but Microsoft takes ASP.Net problems seriously.

I sat up and took notice when Microsoft released not one, but two interim fixes to an announced flaw in ASP.Net, and released them fairly quickly. This is not SOP in Microsoft Land. The original report actually came out weeks ago and somehow flew under the radar until just the last few days. To be honest, Im still not sure just how many sites are actually vulnerable, but I take all the attention Microsoft is paying as a sign that its a large number.

And no surprise there. According to Netcrafts write-up on the bug, there are currently 2.9 million active ASP.Net sites on the Internet. Certainly a large number of those have no authenticated pages and are therefore not vulnerable. Clearly a large number are just developer systems, test sites and default installations with nothing of interest. But just as surely, a large number are critical e-commerce and other such sites, and their privileged pages are vulnerable to unauthorized access.

Actually, those admins have two options for fixing the problems and Microsoft moved before, to my knowledge, any attacks based on the problem.

Im still unclear on how many systems are vulnerable. I tested it against a few ASP.Net systems with authenticated pages and couldnt get it to work. I stopped at that point because I didnt want to look like the wrong kind of "researcher," but it could be coincidence. Its possible the sites I tested had already applied one of the fixes or were one of the exception cases.

Notwithstanding the usual baloney from some places, applying the source code solution provided by Microsoft is trivial for the applications programmer. You just paste a few specific lines of code into a specific file, once per application. Seconds of work. As some have observed, the checks in this code are arguably good to have even in the absence of this bug. But it probably does impose a performance burden on an application. A busy program will pay a heavy price, since every request to the application performs the checks.

Even easier to implement is the ASP.Net ValidatePath Module provided by Microsoft. The installer for the module creates entries in all Machine.config files on the system to have it run the checks in the module for all requests. This might be faster than the source changes to global.asax because ValidatePath is added to the Global Assembly Cache, but I dont think anyone really knows yet.

One could argue that the multiplicity of solutions to the problem is evidence of the flexibility of .Net, and one would not be wrong. I especially like the way the ValidatePath Module works. It should be fairly easy to test and, if it causes a problem, which is highly unlikely, easy to remove. Only Microsoft would have the nerve to use an incident like this for positive marketing purposes, since the bug itself shows some embarrassingly sloppy programming, but I wouldnt put it past them.

Microsoft is making it easy to upgrade—to a non-IE browser, says eWEEK Labs Director Jim Rapoza. Read more here.

So why was this so serious that Microsoft went "out of cycle" to put together two workaround fixes prior to issuing an actual patch to ASP.Net? Im still stumped on it, but perhaps the real question isnt why they moved so quickly on an ASP.Net problem, but why they take so long on browser problems—the ones we have come to know and fear.

For insights on security coverage around the Web, check out Security Center Editor Larry Seltzers Weblog. I dont have an answer Im really confident in, but maybe it has to do with ASP.Net being in a competitive market and Internet Explorer not having serious competition. Oh yeah, Ive read a few stories, even here on, about Mozilla share increasing, but I still dont believe its a meaningful change. Maybe if there were a real alternative for the average user, things would be different.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms Security Center at for security news, views and analysis.
Be sure to add our 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