Sounds like a virtual sleeper cell ...... and very useful too, for Future Perfect Event Management.

Since when is a stability issue on a web server NOT a security issue?

I thought that Denial Of Service fell under the purview of "security", and isn't a remotely exploitable "system instability" a potential DOS vector?

And they left it unpatched for two years?

I must be missing something...

All of you out there who are whining that Firefox is getting nailed for vulns need to notice that Mo puts out patches within days, if not hours. It's taken MS how long???

I need to price out airfare to Vegas, I may have to go to Blackhat after all.

Given that IIS 5.1 only exists on Windows XP (Windows 2000 uses IIS 5.0 and Windows Server 2003 IIS 6.0) you can see why perhaps this is perhaps much less of an issue than the article makes out, and indeed why Microsoft took their time issuing a fix. Probably because they're fixing problems that could have real implications, such as those with core components of the OS that are installed by default.

IIS 5.1 is never going to be used for anything more than a little hobbyist hosting and IT department utilities; I have an FTP server that I turn on when I need to reinstall the Dell utility partition on to a replacement disk for instance.

It's roughly the equivalent of saying "there's a security issue with running Exchange 2003 on XP Professional". No-one would be doing it in a production environment, and anyone who did deserves everything they get frankly.

And yes I know you can't install Exchange 2003 on XP Pro before you get all pedantic, but I'm just trying to illustrate a point.

It is astonishing that modern systems use system architectures that do not automatically prevent buffer overflows, dangling pointers, and similarly pathological situations.

There are -- and have been for a very long time -- any number of system architectures that simply do not allow such situations to arise. Methods include completely separating object code from data areas, providing hardware checks on all memory accesses, and automatic garbage collection for all processes.

As matters stand, avoidance of the resultant problems rests on the shoulders of the programmers, and given the size of modern programming teams, it is inevitable that no software is entirely free of such glitches. From my p.o.v., it's time to abandon architectures that allow these types of programming errors to be made in the first place.

The sad part is that the Intel architecture is quite capable of supporting such hygienic measures -- or so I have been led to believe.

"The sad part is that the Intel architecture is quite capable of supporting such hygienic measures -- or so I have been led to believe."..... QuITe, RW, but then those feeding at trough through all the glitches and backdoors would rebel. IT does though raise the Spectre of an Untouchables Units doing IT on their Own Terms and Conditions and Creating a Universal Virtual Force of InterNetworking CyberIntelAIgents. Hmmmm.... CIAI2 Q Intel ? I shall ponder that Carnivorous thought with AI Mind towards HyperVisionary Echelons....... You just never know what crawls out of the woodwork whenever all the work has been done and the sniff of tasty meal beckons. And if IT smells good IT invariably always is, is what I say can be Imagined for Real.

Ah well, All done here until tomorrow is Friday, BOFH day normally. Simon always manages to brighten up even the Sunniest of days. I wonder if his pointy dangler will be threatening.....:-)

This is a pretty standard dumb programing error

storing pointers in unreachable places so the compiler

can't do it's job is a C programing 101 first program

kind of mistake

these instances prove you are never too experienced

to make a beginners error.