Slashdot Mirror

← Back to Stories (view on slashdot.org)

.NETly News

Posted by ryuzaki0 on from the honk-if-you-remember-netly dept.

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.

11 of 291 comments (clear)

  1. Story not complete by estar · · Score: 5, Informative

    .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.

    1. Re:Story not complete by kawika · · Score: 4, Informative

      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.

  2. Re:Wait a second by benploni · · Score: 2, Informative

    No, you're thinking of Slate.

  3. Re:No buffer overflows? by Anonymous Coward · · Score: 1, Informative

    The compiler itself is not written in .Net. It's a C++ app. How about getting some facts before extrapolating that all new Microsoft apps are written using the .Net framework?

  4. Compiler: Stackguard! by irregular_hero · · Score: 5, Informative
    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.

  5. Re:Perl, Python under .NET? by Anonymous Coward · · Score: 3, Informative

    Just to clarify:

    Visual Perl and Visual Python are development environments for Perl and Python for people that are using Visual Studio.

    PerlNET takes any Perl code and wraps it up as a .NET component so that it can be used in any .NET application.

    If there is enough interest in a PythonNET, we will build that.

    -- Dick

  6. Michael, why must you be so ignorant? by Zico · · Score: 4, Informative

    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.


  7. Re:Guttenberg, Babbage, & Gates by KatieL · · Score: 2, Informative

    The parts could be made accurately enough at the time - there are issues with the accuracy, in that all the components needed hand tweaking to get them to work properly together (And would even with today's manufacturing tolerances - because the errors cascade) which means the machine's parts aren't interchangeable (which was one of Babbage's goals) and that the thing needs debugging - you need to run some stuff though it knowing the right answer and tweak it until the answer it gives matches.

    The reasons Babbage never developed a prototype are different from different sources. He spent a LOT of the money he was given for the analytical engine designing the (more general purpose) difference engine.

    Eventually the government got fed up of giving him money - he'd burned through a /frightening/ amount. ISTR it was of the order of 15,000 pounds, at a time when building a steam locomotive and delivering it to the US was all of 700. [Mentioned in the science museum display].

    In addition he fell out with his leading craftsman who he accused of padding the contract, and spent quite a lot building workshops and so on at his house in order to develop things on-site.

    The analytical engine was definitely acheivable at the time. The difference engine more doubtably so. But while the technology was willing, the project management was missing. Something the IT industry still hasn't learned...

  8. Re:I dare you. by Anonymous Coward · · Score: 1, Informative

    http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cpguide/html/cpovrintroductiontonet frameworksdk.asp

  9. Re:I dare you. by Oink.NET · · Score: 3, Informative
    Please post a link, possibly one from Microsoft.com that explains what .net is.

    The Simplest Way to Define .NET by Sanjay Parthasarathy, Vice President, Platform Strategy, Microsoft Corp.

  10. Re:Perl, Python under .NET? by Anonymous Coward · · Score: 1, Informative

    Perl.NET is a wrapper generator. You decorate your Perl code a bit, and their tool generates a C# wrapper that can invoke the code, which is compiled into an assembly.

    This lets you use Perl code from .NET, but it's not compiled into IL.