These are genuine questions, it would be great to hear your answers about these things :)
Same underlying machine model => same mitigation techniques apply as in C.
> surface area of the C++ runtime itself
No RTTI and no exceptions => no runtime. (By "runtime" I mean code necessary to support language features, not the C++ standard library. E.g., without RTTI and exceptions C++ is as suitable for building an OS as C is.)
Still, RTTI and exceptions are table-driven and I'd worry about their integrity if somebody manages to change the RTII and exception tables embedded in the executable. Largely prevented by signing executables. (Oh, the irony :-))
> How do you find auditors for C++ code [..cut]
More than half of the standard text is dedicated to standard library. I've heard it been said (I've not checked myself) that the description of the core language is only slightly longer than that of Java or C#.
But standard size is not that relevant. Reasonable C++ code is easy to write (for an experienced developer), easy to understand, and auditors can always "fail" the code if they don't know what's going on.
Auditing is expensive, so you have a lot of incentives to write reasonable code from the start.
Here is a comment which links to a talk in which Herb Sutter says it:
Neither is C++. People writing new systems level code should seriously consider safer languages. ATS, Rust, Mercury, OCaml, SML, and many others.
That said I'd hope that systems like ATS, Mercury, MLTon and OCaml being open source make it easier to contribute to the implementation for issues that come up and this would offset any 'not enough real world' problems that they have. If you don't like those languages, pick another (eg. Haskell).
[1] http://en.wikipedia.org/wiki/Prince_XML
[2] http://www.missioncriticalit.com/technology.html
[3] http://mmpool.bitparking.com/pool
[4] https://blogs.janestreet.com/category/ocaml/
[6] https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung...
Maybe C++ is better suited, maybe it isn't. I don't care. It's not the problem here.
The problem is poor test coverage and code auditing. You could rewrite it in prolog for all I care, it doesn't address this core issue. Don't miss the forest for the trees.
This is a straw-man. A bug in the destructor would lead to resource leaks and to eventual program failure. "Slightly" different from a complete and silent failure to perform a critical security task.
> Bugs happen, in any language.
Another straw-man. Some languages are more conducive to certain types of bugs. See PHP for example.
> You could rewrite it in prolog for all I care, it doesn't address this core issue.
The core issue is bad software engineering. If you look at the code more closely, it doesn't even use a consistent convention for signaling failure. The code looks something like
if (ret < 0) { ... goto fail; }
The bug wouldn't be there either if they just settled on using the POSIX convention of negative return value meaning failure. But no.., they have to translate it to a pseudo-boolean stored in an int.
Maybe it would make it harder to introduce this kind of bug (after all, goto error handling could be considered a hack because C lacks proper exceptions) but no language is bug-proof by design. If you're writing security-sensitive code you should have complete code coverage with tests. If you have that you could implement the library in assembly for all I care.
I'm not attempting to bash C++, it's a language I use from time to time. And I agree that RAII is a convenient patter that I often yearn for in C. It's just that in my opinion in this case (and in the "goto fail" bug of late) that's not the core of the issue.
IMO, C is no longer suitable as a systems programming language. It has stopped being that a long time ago, and its only value is ABI stability. (COM and similar technologies work with C++ and other languages, so C is unnecessary even for that purpose.)