On 9/2/2012 1:12 AM, Florian Weimer wrote: > * John Nagle: > >> We have proposed an extension to C (primarily) and C++ (possibly) >> to address buffer overflow prevention. Buffer overflows are still >> a huge practical problem in C, and much important code is still >> written in C. This is a new approach that may actually work. > > Would you please state publicly if you have any IPR claims necessarily > infringed by an implementation, or if you aware of any such claims by > others?
I have no IPR claims in this area. At the language level, I doubt that anyone does, or could. However, there is the potential for a static analysis tool that automatically retrofits sized declarations to existing code, turning non-strict code into strict code. Some of the commercial static analysis systems may have IP in this area. It would probably be narrow, though; proof of correctness systems have been around for a while. I worked on one decades ago, the Pascal-F Verifier. > I'm not sure if the proposed extension would actually help. At work, > we have a coded corpus of vulnerabilities to answer such questions. > For memory safety vulnerabilities related to buffer overflows, the > coding is not yet very accurate, mainly due to lack of a widely > agreed-upon taxonomy, but at least it can serve as a starting point > for a review. There is an "official taxonomy", in “Information Technology — Programming Languages — Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use”, ISO/IEC TR 24772. The current draft is at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1583.pdf It's a list of features in programming languages that offer attack points. It can be used to classify programming language vulnerabilities, to classify attacks which exploit those vulnerabilities, or to classify program bugs which relate to those vulnerabilities. At the language level, for example, C has vulnerability 6.10, "Unchecked array indexing". > That being said, it's certainly a very interesting topic! This is a problem that should have been solved a long time ago. There are programmers who think it's inherent that a fast, low-level language must be unsafe. In fact, many of the vulnerabilities in C simply reflect what could be crammed into a compiler that had to run on a PDP-11 with a 64K address space. Others have approached this problem. They either came up with a new language (Modula, Ada, Java), changed C so much it became a new language (Cyclone, Microsoft SAL), or had to add extra run time data to carry around size information (Safe C Compiler, GCC fat pointers.) The problem today is coming up with a backwards compatible solution that can be applied to the huge legacy C code base. This is tough, but not impossible. I'm proposing an optional "strict mode" for C, in which array sizes have to match in all the places where a mismatch creates a vulnerability. In non-strict mode, today's loose rules apply. Non-strict mode code can call strict mode code and vice versa. Non-strict mode code can use the strict mode features. This provides a migration path to converting security-critical code to strict mode. There are other C "tightening up" proposals around. Most are on the library side, and address the usual suspects - memcpy, strcat, etc. This is broader, deals with arrays in general, and covers the usual suspects as well. John Nagle
