The Microsoft .NET team answers security concerns
1. Code and platform security
2. MSIL compilation options
3. Reverse engineering of .NET code
4. Performance, specifically that of C# compared with VB.NET
5. The team's favorite .NET language
Members of the .NET platform team addressed all of our topics, except for the last one: The developers felt that endorsing a language as their favorite ran counter to the spirit of the .NET platform. Read on for the first half of the interview.
Those ".NET viruses" aren't
Builder: We've seen reports recently of a first generation of viruses designed specifically to take advantage of the .NET architecture, and Microsoft has been rather roundly criticized of late for how seriously it takes security issues. How secure is .NET, from a standpoint of code and platform security, and how prominently did securing the platform figure in your plans?
Brian LaMacchia, software development lead on security in the .NET Framework: So far, there have been two so-called ".NET viruses." Neither of these took advantage of the .NET architecture or breached the security infrastructure of the .NET Framework. The "Donut" virus released back in December was actually a pretty standard Win32 virus. The more recent "Sharpei" virus presented a scenario where the user elected to download and run a piece of .NET Framework code on their local disk. In making this decision, the user granted that code full rights to the local machine. Thus, the virus was not exploiting a vulnerability in the .NET Framework but was simply working within the context of the freedoms the user allotted to it.
That said, security is our number-one priority on the .NET Framework, no question about it. We began thinking about it from the very start four years ago, and security factors into the .NET Framework in a couple of ways.
For one, we have what we call evidence-based and code access security. These technologies give administrators powerful, granular control over what resources can and cannot be accessed by applications running on their systems, and [they] allow an administrator to set it up so that only code signed with a particular key, coming from a particular URL, bearing a certain hash value, etc., receives the right to access the local disk. All other code runs in a more constricted environment, again devised by the administrator. [These security measures] would have prevented "Sharpei" from achieving its aims.
Then, we have role-based security, making it easy for developers to implement authentication/authorization logic into their applications and giving them a good deal of flexibility in the choice of algorithms for these purposes.
Finally, we have our cryptographic libraries—a thorough set of easy-to-use APIs, providing all the major, popular algorithms for doing things like random number generation, encryption, digital signatures, hashing, etc. It's quite a progressive set of libraries, including some major recent advancements like XML Digital Signature.
Security was priority one
Brian LaMacchia: Long story short, we've built security into our platform
from the ground up, but getting the architecture right is really only half the
story. In the summer of 2000, as part of what is now known as the Trustworthy
Computing Initiative, we brought in two of the leading information security
assessment firms, Foundstone and Core Security Technologies, to
review our security architecture and implementation. You can read about that and
their findings on MSDN.
In December, as a continuation of Trustworthy Computing, we trained the entire development, testing, and program management team (around 1,000 people) on security issues and had them spend the entire month reviewing the .NET Framework and Visual Studio .NET for security issues. We're proud to say that both products passed with flying colors. But our job isn't done.
It's a simple reality of the software industry that software isn't perfect. We've gone the extra 10 miles in testing and reviewing the powerful security infrastructure that we built, but at the end of the day, where you'll really see the difference is in our servicing process. We have a team lined up to handle any issues—security or otherwise—that might arise with the product. We've learned from the past—situations like Nimda and Code Red, where patches had been available for months but simply hadn't been installed by systems administrators. This time around, we're delivering our patches via Windows Update, so users and administrators can be proactively alerted when new critical updates are available. What's more, we'll be delivering our patches as roll-ups, so that when you download one, you get all the fixes issued since the last service pack or version release.
Again, security is our number-one priority. And it is through a combination of these factors—secure platform, extensive review, solid servicing plan—that we will provide a product that meets our customers’ needs and expectations.
"Just in time" to dispel your confusion
Builder: There's some general confusion about the various compilation options and their performance consequences. Could you explain how JIT and install-time compilation works and the performance consequences of each option?
Jim Miller, lead program manager on the Common Language Runtime: By default, code on the .NET Framework is just-in-time (JIT) compiled. Effectively, a block of code is translated from MSIL (Microsoft Intermediate Language) to x86 at runtime the first time that the compiler hits that particular method. The resulting x86 instructions will be stored and made available for the duration of the application's execution. Thus, if the application calls that method again, the processor jumps directly to the x86 instructions; there's no need to recompile the MSIL. Once the majority of methods have been JITed, the additional cost of JIT compiling the rare method that hasn't yet been called is not noticeable.
At and around startup time, however, when all or most of the application's methods still have to pass through the JIT compiler that first time, application performance naturally takes a hit. As a result, we also provide the option to pre-JIT (also known as NGEN for Native Image Generator) the code. This translates the MSIL directly to x86 prior to runtime and avoids any such startup latency. In short, if startup time is an issue, pre-JITing your code is the way to go.