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…
Ranged Integers and Saturation Semantics
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.
Continue Reading »
justin January 14th, 2007
We’ve added Chapter 2 - Design Review and Chapter 3 - Operational Review to The Vault, putting the tally at chapters 1, 2, 3, 5, 6, 9, 14, 15, and 17. We’re now at the halfway mark as we continue to work through the remaining chapters. You can expect an update post whenever we add new chapters or make a significant change to existing chapters. One particularly interesting thing in this round of updates is a link to The Protection of Information on Computer Systems, a 1975 paper by Jerome H. Saltzer and Michael D. Schroeder. It’s really fascinating to think that the field of software security had already seen such major development as much as 30 years ago—a bit humbling too.
The reviews are still coming in too. Tom Duff posted a very positive review on his blog and at Amazon. We’ve also started to receive some useful critical feedback through other channels. We’re always happy to get intelligent criticism so we have an opportunity to improve the book with supplementary content here or, hopefully, through a second edition.
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.
Continue Reading »
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 6th, 2007
Stephen Northcutt (of SANS fame) was kind enough to let us ramble at length on a few topics. The interview is a departure from our usual technical focus, as it’s mostly a discussion of our views on how an SDLC and supporting processes affect software security. The subject was a nice change of pace, and let us present our approach to software security to a different audience. You can read it here: http://www.sans.edu/resources/leadershiplab/interview.php
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 »
