Note: Jeff Duntemann replied to this email. See it and my comments on this meme: http://www.memestreams.net/users/acidus/blogid4583591

] If you give reports of recently discovered security holes
] in all major products (not merely Microsoft's) a
] very close read, you'll find a peculiar similarity
] in the bugs themselves. Most of them are "buffer
] overflow exploits," and these are almost entirely
] due to the shortcomings of a single programming language:
] C/C++. (C and C++, are really the same language at the
] core, where these sorts of bugs happen.) Virtually all
] software written in the United States is written in C/C++.

Mr Duntemann. (jduntemann - @ - coppertown.com)

I was completely very confused by your editorial in Software Development Times, " The Lessons of Software Monoculture. As a computer engineer student at a major university, as well as a published author in the same "black hat" publications you refer to, I don't understand any of your claims about C/C++. Any language that makes function calls can have buffer overflows. Its is not something inherent in a language. If anyone is to blame, it is Intel for allowing an executable stack. As I'm sure you know, buffer overflows stem from writing beyond a buffer to overwrite the Stack Pointer and Frame pointer, thus changing the flow of execution to hostile code, usually inside the allocated buffer.

Yes, C and C++ in their base do not have a mechanism to test if a pointer operation is happening beyond the bounds of the allocated memory. In C++, smart pointer classes exist that keep track of things like that, and also will automatically free memory once no more pointers point to it. C/C++ are built for speed. Global pointer checking would drastically slow down the language. The problem is solved by programmers simply doing a check. Macros should even be defined to do it all for you.

My point is your claim that Buffer Overflows are the language's fault is false. It's not like the language is a mystery: it'd well known thatC/C++ has no bounds checking or no garbage collection. Any programmer who uses the language without taking the appropriate steps to protect against out of bounds access is at fault. They have no business coding applications if they don't understand what they are doing. IE: 2 year associates degrees or bullshit certifications do not a good programmer make, and all the security hazards written into the code is not only the"programmers" fault, but also the management structure that would let such an under qualified person write important applications. Further you claim this "problem" with C/C++ makes switching to something other than Microsoft "problematic." Certainly buffer overflows exists in BSD, Linux, and other alternatives. However a buffer overflow on a non-Microsoft has limited damage potential, due to the structuring of the security model.

I thank you for your time, and look forward to hearing your views on these matters.

C/C++, not Microsoft, to blame for Window's Bugs!