.NETly News

Lots of .NET stories in the news today and yesterday; it's a total coincidence that Microsoft started a huge marketing push on Wednesday, including the occasional Doubleclick ad running on Slashdot. BrendanL79 writes: "Peter Wright at Salon.com contributes to public awareness of Microsoft's .NET with this exuberant piece. The praise borders on sycophancy ("Gutenberg ... Babbage ... now Gates") with no apparent tongue in his cheek. Comments?" Reader vw writes: "Active State has just released Visual Perl 1.2, Visual Python 1.2, and Visual XSLT 1.2 as plugins for Microsoft's Visual Studio .NET. Wonder how long it will take for a Mono hack." Numerous readers pointed to several stories about a buffer overflow problem in Visual Studio .NET which was supposed to be immune to buffer overflows - but it had passed Microsoft's stringent new security audit.

Comments

Story not complete

[estar]

.NET is many things and many people are confused by what .NET exactly refers too. In the context of this story .NET is refering to the compilers, and libraries that make up Visual Studio.NET. VB.NET, & C# are both geared toward using the CLR and .NET Framework. Visual C++.NET can use the CLR and .NET Framework but, unlike VB, you can work with Visual C++ like you could in previous versions and ignore the CLR and .NET Framework. So what is the security error reported? This is the detail as reported by Cigital. The protection afforded by the new feature allows developers to continue to use vulnerable string functions such as strcpy() as usual and still be "protected" against some forms of stack smashing. The new feature is closely based on an invention of Crispin Cowan's called StackGuard and is meant to be used when creating standard native code (not the new .NET intermediate language, referred to as "managed code"). This is a problem with Microsoft's Version 7 C++ compiler not with the CLR and .NET Framework.

Re:Story not complete

[kawika]

Exactly. All Cigital seems to be saying is that unmanaged (unsafe) code is still subject to buffer overflow problems. This is not news, and it's why you have to jump through some hoops in .NET to use unmanaged code. Those of you who visited Slashdot yesterday may remember this item about .NET that explains it a bit.

Microsoft's alternative, of course, was to create a totally safe environment that wouldn't run any legacy code and wouldn't allow direct calls into the OS. But of course that's been done before (Java). Remember, .NET isn't just for developing network apps, it's for developing local ones as well. If there's already a proven DLL, COM object, or system call that does what I want to do for a local app, I would prefer to use it than reinvent the wheel inside the sandbox.

Compiler: Stackguard!

[irregular_hero]

Look here for additional details on the compiler buffer overflow.

It's not actually a _compiler_ overflow.

Instead, it's a subversion of the "buffer overflow protection" that's built-in to the compiler. The most startling piece of this technical review is that the Microsoft "Overflow Protection" in the compiler appears to be a port of StackGuard. The reviewers point out that an examination of the binary output reveals that the compiled code is nearly identical to the StackGuard output.

Michael, why must you be so ignorant?

[Zico]

From the summary (yes, it was written by Michael, not the submitters): Numerous readers pointed to several stories about a buffer overflow problem in Visual Studio .NET which was supposed to be immune to buffer overflows - but it had passed Microsoft's stringent new security audit.

Where to begin with this mess of falsehoods?

• This isn't a VS.NET buffer overflow, it's about a way to attack code generated by the Visual C++ compiler when the /GS compiler switch is used.
• Nobody ever came close to claiming that VS.NET would automatically create C++ code that would be immune to buffer overflows. The boldest claim I've seen Microsoft make is "Also, the Microsoft® Visual Studio® .NET C compiler has support for a new /GS switch that protects your code from many common buffer overrun problems." There does indeed seem to be a flaw, similar to what makes StackGuard attacks possible, but even if you get rid of this problem, it wouldn't be immune to programmers writing potential buffer overflows into their code -- the only thing that these tools do is try to get rid of the most common errors.
• The security audit was about making sure that one's computer/network isn't made vulnerable by having Visual Studio.NET installed on it.

On a side note, since this only affects unmanaged code, it's not really related to the .NET/CLR stuff.