eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
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.
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 eWEEK.com, 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.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:
More from Larry Seltzer