...you'd think that developers would finally know how to write software that doesn't have such vulnerabilities.
But unfortunately we don't seem to have made that much progress, despite the reasonably large number of development tools we have that address such issues (including anything from memory debuggers to string libraries). I mean, really... people are still writing these things in C... in the 21st century! I'm a big fan of picking the right tool for the job, but I think it should be clear by now that C isn't the right tool for writing secure software. There are simply too many ways to screw up.
I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.
You might still have to worry about buffer overflow exploits against the kernel, but that's a much more manageable problem.
Slashdot Mirror
But unfortunately we don't seem to have made that much progress, despite the reasonably large number of development tools we have that address such issues (including anything from memory debuggers to string libraries). I mean, really ... people are still writing these things in C ... in the 21st century! I'm a big fan of picking the right tool for the job, but I think it should be clear by now that C isn't the right tool for writing secure software. There are simply too many ways to screw up.
I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.
You might still have to worry about buffer overflow exploits against the kernel, but that's a much more manageable problem.