[In reference to your Q&A from last issue defining buffer overflows] I sent out your articles to our web application developers, and they are using Macromedia ColdFusion 8 and .NET 2003. They responded with the answer below saying they are not affected by memory overflow. Any comment on what's been said?
"Since the CLR for .NET and the JVM for ColdFusion manage memory independently from the operating system we can not cause serious memory problems to the point of crashing the servers. Certainly the risk of outsiders doing this exists but no-one needs to worry about me writing a poorly coded application causing memory leaks. Unless we start coding in C/C++, we are safe from this."
eEye security specialists anwered the question in this way:
There are two major points to address: First, if you can do low-level work, you can most likely create memory access problems. Second, the system that processes your code could itself have problems -- you should never make assumptions that the problem is completely taken care of by someone else.
It is okay to say, "I work in a very safe environment, and it is very unlikely that I will have any memory access problems", but thinking that you will not ever have memory access problems could keep you from ever learning and understanding the potential problems.
There are also potentially countless security bugs not related to memory access in these products, and these can be even harder to find and test for than the memory access problems. Understanding secure coding from all angles will be the key factor for developing secure applications.
I asked Marco Russo, a well-known .NET and Business Intelligence expert, to further comment this topic:
While any platform could have bugs and security vulnerability (at the end, even a microprocessor could have a buggy behaviour for a particular instruction), .NET offers a relatively high security bar agains memory overflow problems if you strictly follow some rules: write 100% managed code, use only managed libraries, don't use legacy components (native-code DLLs and COM objects).
The pitfall is that the current .NET Framework is based upon a legacy platform and use a lot of legacy components (DLLs and COM objects) that could have wrong behaviours if a new vulnerability is discovered.
There are a lot of controls made by interoperability services of .NET Framework to reduce exposed area (like parameters validation), but there can't be a 100% secure way to validate any parameters while we can't assure that a vulnerability exists for a given combination of valid parameters.
That said, I think that writing managed code is a safer way to write software than writing unmanaged code. You can leverage on a lot of services that catch more common problems in your code. I don't like positions that can promote the idea that "writing all the code by yourself without relying on existing platforms/libraries is better".
The real message should be that security is a complex matter and you have to be aware of features and pontential weakness of tools you use writing code.


