Customer Reviews

Secure Coding in C and C++

5 star:		(7)
4 star:		(1)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

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 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.

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.

This book covers the major areas of security that C/C++ developers should be aware of. Topics like stack smashing, dynamic memory management, integer security, strings, and others are covered. The author is able to describe these complex topics in a way that is accessible to the reader. In my opinion both students and professional programmers should read and understand this book.

I had the honor of taking a short course at a software security summit from Robert Seacord. I would have to say it was one of the most informative security related courses that I have taken. This book encompasses the course that I took and does a great job of explaining what to watch out for when writing code.

I highly recommend this book for any serious developer.

This is one of the few books that every C and C++ programmer should read. It shows detailed examples of the very undesirable sorts of things that attackers can force badly written code into unwittingly doing; it also explains how to create multiple layers of defense around the bad code that inevitably finds its way into real programs. The book is well written; I will concentrate here on the relatively minor defects.

First: Many sections of the book are of necessity really, really boring. The chapter on integer security must set the record for most boring chapter ever written in a programming textbook. Fortunately, most of the boring parts can be skimmed over. For example, once you grok the basic idea of how an attacker can exploit a buffer overflow to overwrite the return address on the stack, you do not need to read the long discussion that shows in gory detail exactly how it is done.

Second: Although the authors are clearly very knowledgeable in their area, the book contains an occasional strangely worded phrase (and in one case a piece of code that does not do what they state it does) that leads me to suspect that the authors perhaps might not have *written* lots of code themselves.

Third: The discussion on the various tools and libraries that are available to mitigate security risks are useful, but strangely irrelevant. I have programmed on a lot of different projects in my life with a lot of different people, and I have met few, if any, people who actually use any of these tools and libraries. Further, the time that would be spent using the tools would in many cases be better spent by simply re-reading your code multiple times to find and remove the awful code that the tools are defending against and that no decent programmer should write in the first place.

That being said, the book is well written and essential reading for C and C++ programmers.