Secure Coding in C and C++

This is an important book for people that write computer programs and their managers. It is also very well organized and well written. Seacord reveals how the bad guys take advantage of bugs in programs to break into a system or damage it. It is the most complete list of exploitable bug types that I am aware of. Many examples are given, naming software that have been exploited by bad guys. Some may protest that this provides the bad guys with a list of easy targets. All of the vulnerable software has been updated to fix the bug, and the improved version has been available for a long time. Everyone that writes software intended to be used by someone else should read this book. Every organization that writes software should have a copy. Most of the security flaws are buffer overflows. Secord shows how, from the simple use of gets() through mistakes triggered by subtle differences in the rules for signed and unsigned integers of various sizes. There are other ways, and some are quite subtle, but still preventable. The bad guys are not Jay Leno's "Dumb crooks." The primary way to frustrate the bad guys is to not have any of the bugs they exploit. Seacord admits zero bugs is an elusive goal and recommends defense in depth by the use of various freeware or commercial packages intended to trap or prevent certain errors. He lists and describes many, with their strengths and weaknesses. Read this book and make your code better. Read it again, next year. The following are my opinions, based on over 40 years writing software, but I doubt Seacord would disagree. Every security bug is also a bug that can cause a crash or a wrong output from a program. The major cause of fewer bugs is the attitude of the programmer. Managers can affect the attitude of the programmers by their choice of questions. Do not ask "Is it done yet?" Instead try approaches like: "Tell me about how you validated the inputs and how you identified all the inputs." "Who reviewed your test cases?" "How did you decide you had tested enough?" The fewer bugs of any kind in your product, the less likely the bad guys are going to target it, other things being equal.

This book slipped under my radar, but I recently picked it up and was quite impressed. This book is fairly unique in that it is accessible and well-written, yet, at the same time, unabashedly technical. It's quite simply a very good book, and it should prove valuable to readers new to software security, as well as experienced security consultants and vulnerability researchers. I know the problem domain intimately, and was quite impressed at the level of thoroughness and the technical depth of the coverage. This book isn't merely a well-written exploration of known insecure programming idioms and attack techniques; there's actually a considerable amount of original research and material that you won't find elsewhere. Specifically, the coverage of integer issues goes above and beyond what has been previously written, and it's incredibly topical given the current trends in vulnerability research. Seacord's mastery of the C language and his ability to distill the practical rules of thumb out of the somewhat fragmented C standards really results in an excellent resource.

There seem to be three categories of computer security books. The first category is books written for system administrators or computer owners, and explains how to protect the computers under their control. The second category is the "true crime" genre that recounts the exploits of black hat hackers or explains the hacker culture (sometimes as "how-to" books for non-programmers). The third, and rarest, category is books for professional programmers that explain the coding idioms that make programs more secure or more insecure. This book is an excellent contribution to the third category. It explains how certain ways of programming in C and C++ make programs vulnerable to security attacks. There are many code examples throughout the book illustrating the issues. Although everything is explained in great detail, the treatment is not superficial. (No background in computer security is required, but the reader should be at least a journeyman C or C++ programmer.) Some of the security holes will surprise readers familiar with the basics of computer security. My favorite example: Many programmers know that the gets() function once was involved with compromising 10% of the computers on the Internet in a single day, but did you know that printf can also be a security flaw in some cases? The statement: printf(s); can allow an attacker to run any code of his choosing if s is a string provided by the attacker. Even more surprising is the printf attack has been used successfully on popular programs. This book should be read by any programmer who does I/O across a network, or who writes applications that provide a captive environment for their users (data entry stations, information kiosks), or who writes programs to manipulate sensitive data. Even programmers merely curious about security issues will find this book a readable treatment. I guess the Black Hats can read the book to get more ideas for future attacks. I can personally vouch for Seacord's expertise. He is a security analyst as the Computer Emergency Response Team/Coordination Center, and I've worked with him on the ANSI/ISO C Programming Language Standards Committee. I've found his information on computer security both educational and valuable. [...]

Seacord gives an unsettling walkthrough of vulnerabilities present in much of C and C++ coding. Buffer overflows take up a significant portion of the discussion. Which leads into considering how these can be introduced into unwary code. Consider C. The common string functions of strcpy, strcat, gets, streadd() and others are shown to be very exposed to error or attack. C++ also has similar drawbacks. The text explains that much of these trace back to some bad usages. Strings are defined to be null terminated. And bounds checking is often not done. While this is often true of code that the programmer writes, it is also true of various common C library functions, like those mentioned above. In fact, Seacord goes so far as to emphatically assert that gets() should never be used in your code. Instead, he suggests fgets() or gets_s(). Seacord also covers other topics, like dynamic memory management, which might have vulnerable heaps. Various 3rd party analysis tools are suggested, to find these errors. Overall, the book can be quite disturbing, if you are maintaining a large body of C or C++ code. Might make you want to delve in and replace those gets(), at the very least. While the text doesn't mention this, it turns out that recent languages like Java and C# have far more robust string handling abilities. They were written after the above flaws in C and C++ become apparent.

This book is not only solid in the technical coverage it gives. It also gives a great overview of security concerns, history of how we got where we are, the types of threats and flaws that exist, who needs to be concerned, and what your role's responsibilities are in the security picture. The technical advice is thorough and explained in a way that makes for a very interesting read. In other words, the author has a great style of writing. This is must read for C++ and C developers, but I would also recommend it for any programmer or architect of any language.