Dynamic languages are susceptible to their own kind of security bugs. I've found lots of bugs in Node apps where they accepted some JSON from the client and then passed it directly into a Mongo query without type-checking it. Or look at Ruby's YAML security issues.
Nearly every language is vulnerable to integer overflow. C++ is one of the few languages (possibly the only popular language) where you can reasonably check for overflows at compile time, as Cap'n Proto now does: https://capnproto.org/news/2015-03-02-security-advisory-and-...
So, I don't accept the assertion that C++ is inherently a security problem.
In any case, Sandstorm's low-level container management bits pretty much had to be written in C/C++ since they interact closely with the operating system. Or if we were starting over today, Rust might now be an option, but it wasn't when we started.
> Dynamic languages are susceptible to their own kind of security bugs. I've found lots of bugs in Node apps where they accepted some JSON from the client and then passed it directly into a Mongo query without type-checking it. Or look at Ruby's YAML security issues.
I don't advocate dynamic languages. Indeed I regard this class of vulnerabilities as evidence of a lack of type safety. Still, C++'s undefined behaviour semantics promote almost all bugs into security bugs, which is not a great property to have in your language.
C++ using that kind of template metaprogramming technique has nowhere near the overall popularity of C++, so that's not really a popular approach either (in the sense that e.g. few tools understand it, people who can work on it are hard to hire...). And any language with a reasonably advanced type system (or macros) could do the same thing.
One doesn't need to use complex template techniques, a class like CSafeInt should cover all integer overflow bugs with run-time checks.
The problem is that almost no one is thinking about this class of bugs. Furthermore, few languages offer tools to detect and handle integer overflows; I read that Rust for example only has run-time checks in the debug version, which to me is disappointing.
> I read that Rust for example only has run-time checks in the debug version, which to me is disappointing.
Only by default; you can turn them on in release builds too if you want. (And Rust 1.17 will have a stable `-C overflow-checks=y` flag which allows you to turn on the overflow checks without other debug assertions.)
> a class like CSafeInt should cover all integer overflow bugs with run-time checks
If that's all you want it's easy to do that in any language? What's so special about C++? The reason this gets talked about more in C++ is that the consequences of integer overflow in C++ are dreadful (undefined behaviour i.e. instant security bug) whereas in most languages adding two integers will evaluate to an integer.
Or Ada 2012 + SPARK 2014 wrapping the C API behind safer interfaces. One can catch most problems, including integer overflow, at compile time or with runtime checks it inserts. The other can prove their absence automatically in more static code. Rust can prevent temporal errors at compile time so it's on table, too.
Nearly every language is vulnerable to integer overflow. C++ is one of the few languages (possibly the only popular language) where you can reasonably check for overflows at compile time, as Cap'n Proto now does: https://capnproto.org/news/2015-03-02-security-advisory-and-...
So, I don't accept the assertion that C++ is inherently a security problem.
In any case, Sandstorm's low-level container management bits pretty much had to be written in C/C++ since they interact closely with the operating system. Or if we were starting over today, Rust might now be an option, but it wasn't when we started.