This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Windows Security Holes in Win2K3 Disconcerting
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
Yesterdays news of yet another buffer overrun security hole was most disconcerting. I am not naive enough to think that millions of lines of unmanaged C++ code won't have buffer overruns in *any* OS (all C/C++ based OS like Linux, Mac, etc will have buffer overruns too), but the disconcerting news is that it also occured in Win2K3. I had just sold management in the company I am clienting for on the ability of W2K3 to avoid these, with the line that during the Windows Security Push, all 9,000+ Windows developers stopped and poured over essentially every line of Windows code remove these kinds of situations and make W2K3 the most secure OS. Now two of these in the last month. To say that this has stopped a massive redeployment is an understatement. The company was looking to just skip Win2000 Server and move many NT4 servers to Win2K. These kinds of situations are simply unacceptable. So is the patching strategy. To require a reboot for every security path installed is simply unacceptable. An OS like Win2K3 should never have to be rebooted and should be able to go a year or more without a reboot. A way must be found to apply these patches without causing reboots. Now that the operating systems have gotten super stable and operate for these kinds of times, we cannot have a patch requiring reboots. Patches like this can be applied to other OS like Linux and Mac OS X without reboots. I hate to bring up the fact that we had VAX/VMS systems up for years in the 1980's. This has just got to get better. If nothing else. this just points to the fact that things need to be written in managed code everywhere (I don't care if its .NET or Java or whatever) and we need to get away from C/C++ as sloppy error-prone and dangerous languages. Efficiency is no longer the issue in this day and age of fast processors and much memory. Code safety and productivity is.
Previous Topic
