Security and Microsoft and .Net
“Microsoft is insecure!” have you heard that before? Yes of course. Everyone is talking about Microsoft products being in-secure. Well very few have actually questioned the fact. What is the cause behind this belief among the computing community?
Well the possibilities could be many. One possibility that goes around the Microsoft communities is that all the computing schools and colleges teach computing in Non-Microsoft technologies, like Unix. Now when they grow up and enter the industry, and see technologies like .Net and Longhorn, they get overwhelmed. Overwhelmed by the rate at which technology is growing. Overwhelmed by its speed and magnanimity.
They want to go back into their safe and secure domain in which they were brought up. So they sub-consciously find ways to downgrade Microsoft Technologies.
Another reason why Microsoft is thought of as insecure is that it comes up with a security patch every other day. Now if it needs to send a security patch every other day, it creates a feeling that the operating system is inherently insecure. Microsoft has realized that its reputation is deteriorating because of this belief and has taken this issue very seriously. In fact last year Bill Gates even issued a memo saying that security would be Microsoft’s top criteria. And later Microsoft even had a security lockdown when every developer had to stop whatever they are doing and had to identify security aspects in their code bases.
Every activity that is happening at Microsoft since last year has security as its primary focus. And .Net has a major hand in it. A classic example given in .Net newsletter May 15 2004 goes like this.
“The C run time library string handling routines are flawed because, in general, they do not have protection against buffer overruns. To counter this, Microsoft generated the strsafe.h file of safe string-handling routines. These routines were developed in direct response to the security lockdown at Microsoft.
Of course, string buffer overruns are not a problem with .NET because of the design of the System::String class. Even if it was possible to access past the end of a string buffer in managed code, this still would not allow a hacker to control your process because string buffers are never allocated on the stack. Even if string buffers were allocated on the stack, a buffer overrun would not give access to the stack because the .NET run time manages access to the stack. Finally, and importantly, .NET applies validation, verification, and code access security checks on all .NET code, and through these checks it determines whether the code has been altered, whether the code plans to do something unsafe, and how much the run time trusts the code and hence what it is allowed to do.”
.NET is inherently secure, it has had security built in from the bottom up. As more and more applications are built using .NET, most security breaches will disappear. As more and more parts of Windows are implemented using .NET, the operating system will get more and more secure.
The .Net framework was made this way because the Microsoft developers discovered that security holes were natural because of the code is located, loaded and executed. Before windows can be made more secure, they had to change the way the code was loaded and executed.