mark August 7th, 2007
Hi!
Well, we just arrived home from Las Vegas on Sunday after delivering our talk at Blackhat about breaking C++ applications. It seemed to be received pretty well. For anyone interested, the slides should be available on their website, but we have also archived them here.
Enjoy!
mark July 9th, 2007
Hi there!
We would like to announce that we will be speaking at Blackhat in Las Vegas (beginning August 1) this year on the topic of C++. The basic premise for the speech is this: Most security literature about vulnerability analysis (or secure programming) for C/C++ tends to only address potential problems that can occur in C (dangerous API calls, integer overflows, pointer arithmetic, and so on). While these problems also affect C++, it is very rare that C++-specific problems are dealt with at all. As such, we are going to speak to a few problems that are specific to C++ and C++ runtime environments. There is too much material to address every potential problem that can occur in C++ in the time we have, but some of the things we intend to cover include VLA’s, the STL, and exception handling. So, if this sounds like your cup of tea, swing by and check it out!
We will also be doing a book signing on the first day of BlackHat at 12.30 PM.
Hope to see you there!
jm February 26th, 2007
A couple of interesting errata, courtesy of Herr Doktor Professor rCs:
Continue Reading »
blog January 18th, 2007
Robert C. Seacord of CERT was kind enough to provide us with the following proposal for addressing integral vulnerabilities in future versions of the C standard. It’s an intriguing approach that we hope generates some good discussion. So, without further adieu…
By Robert C. Seacord
In 2005, I wrote that "Integers represent a growing and underestimated source of vulnerabilities in C and C++ programs" as the lead sentence in the "Integer Security" chapter of Secure Coding in C and C++. This prediction has been borne out in a recent study published by MITRE on the types of errors that lead to publicly reported vulnerabilities. "Integer overflows, barely in the top 10 overall in the past few years, are in the top 3 for OS vendor advisories."
Fortunately, some individual members of the ISO/IEC WG14 international standardization working group for the programming language C are starting to mull over some options for addressing integer issues. One idea is to adopt ranged integer types; a second idea is to implement saturation semantics for at least signed integer types.
mark January 9th, 2007
In languages that have direct memory access, string manipulation has always been tough to get right. When the dangers of buffer overflows were first realized, many applications that did any sort of string processing were found to have vulnerabilities that we would now consider to be obvious. Over the years, system string APIs have been updated, refined, and replaced. Interestingly, these various replacement functions have exhibited additional quirks, which can render an application vulnerable in more subtle ways than with standard buffer overflows. Some of these quirks are quite well-documented and well-known (such as the strncpy() function not NUL-terminating), and some of them are not. Windows actually provides quite a large number of string functions, each with their own subtle variances. It is important as auditors to know these differences so that you can accurately assess whether an application is vulnerable to potential memory corruption issues or not. With that in mind, I’ve put together a series of tables of quick facts about the various string functions available in a Win32 programming environment that should be useful as a reference when auditing string manipulation routines.
jm January 7th, 2007
You should check out the CERT Secure Coding Standards. We’ve started contributing to them recently, as we think they are interesting and quite well done. The standards are a community effort and a work in progress, so feel free to help out. The best way to start is by leaving comments on the appropriate pages with your ideas and/or criticisms.
One aspect of the system that I think is particularly good is the separation between rules and recommendations. Rules are things that you definitely don’t want to do in your code, as you’re very likely shooting yourself in the foot. Recommendations are more best practice coding standards or idioms that will buttress your code base against attack or help inform program design. So, for example, there is a rule that says "MEM31-C. Free dynamically allocated memory exactly once." Double frees are obviously something categorically bad, and should never occur in production code. An example of a recommendation is "MEM00-A. Allocate and free memory in the same module, at the same level of abstraction." This is absolutely sound advice. However, it’s a recommendation and not a rule because there are situations in real-world code where you might have solid reasons for violating this design. I think it’s this subtlety of analysis that will make the standard actually useful in real-world development efforts.
It looks like it will be a useful resource for its intended purpose as a baseline for secure coding standards. (i.e. if you need to put together secure coding guidelines for your organization, it should be a great starting point.) That said, it’s also useful for code auditing, as the rules encapsulate a lot of ideas about what can go wrong in code. It’s approaching the problem from a slightly different angle, but in general, for every rule, there are one or more implied insecure practices that you can audit against.
A quick plug: Robert C. Seacord is one of the chief contributors to the effort, and we might be able to coerce him to do a guest post later on. If you haven’t bought his book, "Secure Coding in C/C++," we highly recommend it.
blog January 3rd, 2007
In C++, objects can be dynamically allocated at runtime using the new operator and deallocated using the delete operator. Arrays of objects, however, require the use of slightly different operators for allocation and deallocation: new [] and delete []. Although the corresponding pairs of operators look very similar in source code, the way they function is actually quite different. Consequently, they can’t be mixed and matched - allocating an array with new [] and then deallocating it with delete, for example, will produce "undefined" results. This can catch developers off-guard, because you can often use the wrong operator without triggering a compiler warning or even causing a run-time crash.
Continue Reading »
jm December 28th, 2006
6.7.2 of the C standard indicates that:
Each of the comma-separated sets designates the same type, except that for bit-fields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int.
So, when you have a bit-field of type int, it’s implementation-defined whether that bit-field is actually treated as a signed integer variable. Based on our limited testing, it appears that mainstream implementations do treat it as a signed integer, which is pretty interesting.
jm December 5th, 2006
So, on page 224, in a note, I wrote:
You might see type conversions referred to as "type coercions" in programming-language literature; the terms are synonymous.
Well, I guess you can tell I got my CS degree from a public school. So, there’s two types of type conversions: explicit type conversions and implicit type conversions. Explicit ones are ones that the programmer explicitly invokes, via type-casts. Implicit conversions are the ones that the compiler does behind the scenes to make everything work. "Type coercions" are the implicit type conversions, not the explicit ones, so the above statement is wrong. While it’s rather fun being wrong while stating things authoritatively, I really hope they don’t revoke my ACM privileges. I still haven’t used my free kill.
This blog provides running commentary from Mark Dowd, John McDonald, and Justin Schuh, the authors of the book: The Art of Software Security Assessment. You can purchase a copy from Amazon, or directly from the publisher, Addison-Wesley, and peruse the sample chapter on C Language vulnerabilities.