Buffer overflows as a security hole aren't only a Microsoft problem -- although you would think they could afford better code reviews -- they are an almost universal C/C++ problem.
First, using fixed-size buffers for strings (and other arrays) seem almost to be encouraged by the language design, or at least by common practice.
Second, strings (and other arrays) unfortunately do not have a size inherently associated with them in the language, and null-terminated strings can be slow to check for length.
Third, the stack layout of typical C/C++ implementations makes it *possible* to overwrite the return address. Some other programming languages I have used had implementations with the return address below the local variables, making it essentially impossible to overwrite.
But then, years ago, nobody ever seemed to think about security issues in language design.
Slashdot Mirror
Buffer overflows as a security hole aren't only a Microsoft problem -- although you would think they could afford better code reviews -- they are an almost universal C/C++ problem.
First, using fixed-size buffers for strings (and other arrays) seem almost to be encouraged by the language design, or at least by common practice.
Second, strings (and other arrays) unfortunately do not have a size inherently associated with them in the language, and null-terminated strings can be slow to check for length.
Third, the stack layout of typical C/C++ implementations makes it *possible* to overwrite the return address. Some other programming languages I have used had implementations with the return address below the local variables, making it essentially impossible to overwrite.
But then, years ago, nobody ever seemed to think about security issues in language design.