|
|
AS OF 7/4/2008 8:28PM EST
|
January 15, 2006 —
C and C++ can be made as safe as managed languages like Java and C#, with a minimal runtime overhead penalty. While no one technique can eliminate all buffer- and pointer-related security holes, there is a set of techniques, libraries and tools that can capture all such holes. Only a fraction of vulnerabilities require runtime instrumentation, making the average runtime penalty for a provably safe C or C++ program in the low single-digit percent realm. This is the claim of Plum Hall Inc. and its “Safe-Secure C/C++” project, at www.plumhall.com/sscc.html.
When I first heard the claim, I commented to a friend that if it were anyone but Tom Plum making it, I’d dismiss it as spam. Those of us who watch the software development industry regularly receive claims of breakthroughs that vastly overreach their capacity; solutions to C’s buffer vulnerabilities are as predictable as visual tools that “eliminate programming altogether.”
 Tom Plum, though, is the compliance guru of the ISO C++ Standards Committee, and his company produces conformance suites that validate C, C++, Java and C# compilers’ adherence to standards. (He is also a friend and neighbor of mine and, in years past, I’ve occasionally consulted to Plum Hall.)
As SD Times columnist Andrew Binstock has ably pointed out in his recent columns, C remains the most important language in the realm of open-source software. I would go further and say that C and C++ remain the most important languages for professional programmers. Not for professional programming, necessarily, but for programmers.
Proficiency in C, coupled with (at least) a working understanding of C++ as a more type-safe version with objects, is the single most valuable technical ability for a professional programmer. This has been shown in every analysis of job postings for more than a decade, as well as being intuitively obvious to anyone who’s been on either side of a technical interview.
The well-deserved acclaim for managed languages has for a decade largely drowned out advances in C/C++. There is ample evidence that it may be time for C/C++’s return to the spotlight, with the arrival of exciting projects like Safe-Secure, C++/CLI and Concur (Herb Sutter’s proposal for high-level concurrency abstractions, which I will discuss in a forthcoming column).
Legacy codebases and performance are the Scylla and Charybdis of C/C++ vulnerability. C/C++’s long history and universality guarantee that essentially all nontrivial projects incorporate large codebases, libraries and complex build scripts. Remediating a thousand lines of code is one thing, remediating a million is entirely different.
Using the safe version of the standard library functions is certainly the first step (hello strcpy_s()), but things quickly move beyond search-and-replace when you get into data structures and unions. On the other hand, you can punt on source-code changes and try a new memory-management subsystem, thinking that “managed languages do this with little overhead,” but doing so has always forced a decision between restricting C/C++ or accepting an overhead that can actually be higher than that achievable in more restricted languages!
Plum’s strategy, though, is not to attempt a single “general case” solution, but to use tiers of strategies and tools, beginning with source-code remediation. He claims that by the time his techniques get to the need for runtime checking, it’s such a constrained circumstance that the overhead can be minimal. To test, he has tackled portions of the SPEC/GPC benchmark suite. Is it surprising that, even in such pored-over code, he discovered vulnerabilities (arising, apparently, from some obscure and unlikely combination of command-line switches)? He claims that the resulting “safe and secure” benchmarks run with less than 10 percent overhead.
If Plum’s extraordinary claims are true, the thing that’s most intriguing to me is the possibility of introducing PKI-style “trust chains” into the execution of software, especially critical infrastructure software such as firewalls and routers. Sadly, Plum says that he faces a chicken-and-egg problem in that the compiler vendors aren’t seeing security at the top of customer demand and that customers are not demanding it because they aren’t aware it’s a possibility. So if you’d like to see C/C++ secured, start screaming.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
|