Secure Programming Cookbook for C and C++

Alex Moskalyuk writes with the review below of John Viega and Matt Messier's Secure Programming Cookbook for C and C++, a book which he says is useful -- but only if you have the background to use it. Read on for the details, including Alex's alternative reading suggestions. Secure Programming Cookbook for C and C++ author John Viega, Matt Messier pages 790 publisher O'Reilly rating 8/10 reviewer Alex Moskalyuk ISBN 0596003943 summary Real-life recipes for using secure code even in the basic algorithms

The Target Audience of the Book In the foreword to this book Gene Spafford observes that there really are four types of programmers:

1. Those who are constantly writing buggy code, no matter what,
2. Those who can write reasonable code, given coaching and examples,
3. Those who write good code most of the time, but who don't fully realize their limitations,
4. Those who really understand the language, the machine architecture, software engineering, and the application area, and who can write textbook code on a regular basis.

There are, as Spafford claims, too many people in category 3 who think they belong to the category 4, and that's the primary target audience of the book. John Viega and Matt Messier co-wrote Secure Programming Cookbook for C and C++ not with the intent of proving the necessity of application security, as they mention in the foreword, but to illustrate its application. If you're reading this book, you are probably well aware of the security needs at your workplace or in your projects, and you would like to have a large library of sample code for various operations.

The book has yet another Web site, and since John Viega didn't mind a little slashdotting during the launching stage, so he probably won't mind another link to SecureProgramming.com.

The Book Itself The structure of the book will be familiar to anyone who has read an O'Reilly Cookbook before. The "cookbook" part of the text is nothing more than a collection of solutions to common problems. The code is generally of high quality and written by an expert in the field. What's more important is the discussion section following the code, which explains why things are done in a certain way, what alternatives exist, and what are the best practices in the field.

Viega and Messier have expanded the discussion session, basically doubling the content, by introducing separate Windows and Unix sections where applicable. The reader has a chance to peruse the code for both platforms as well as read separate discussion sections, which helps in navigating the content of the book.

Microsoft platform developers, though, will only be introduced to native Win32 API -- the authors chose to ignore the STL/ATL/COM/DCOM/.NET solutions on the assumption that those could be derived by someone closely familiar with the lowest-level API available from Microsoft. Even though the discussion section is quite detailed and informative for both Unix and Windows developers, the authors do not discuss the design and architecture issues behind secure programming in C and C++. That falls outside the scope of this book; besides, John Viega co-authored Building Secure Software , where a lot of attention is paid to the philosophy of secure programming as well as initial application design with security in mind.

The Contents You can view the table of contents on the O'Reilly Publishing Web site, and with the cookbook format, it's pretty much WISYWIG -- whatever the title of the subchapter is, you will be introduced to the nature of the problem, followed by C/C++ solution, followed by the discussion of the subject with occasional URLs to relevant information on the Web.

Just to sum it up, usage of encryption, message integrity checks, symmetric and public-key cryptography and secure programming get a lot of attention. With 41 recipes (Chapters 4 and 5) on symmetric encryption and 29 (Chapters 7 and 10)on PKI-related code snippets, you can get your yearly supply of Unix and MS CryptoAPI examples.

But this book is not entirely about encryption, since current security problems are rarely caused by the encryption algorithm failures. The networking and Internet-related programming issues are covered in Chapter 8 (Authentication) and Chapter 9 (Networking). In Chapter 3, those designing Web interfaces will find some useful examples of validating the input URL and checking the SQL string against injection attacks. Admittedly, such examples would serve a better purpose in Perl/PHP/ASP, however, anyone familiar with C should be able to derive their own variations of the algorithm. Chapters 1 and 2 provide a great deal of insight into operating system specifics in regards to such system security issues as environment variables, spawning child processes, revealing memory dumps, using temp files on Windows and Unix, etc.

Off-the-beaten-path chapters include information on random numbers (the chapter is available online for free) and preventing tampering with applications. The random number chapter would be interesting to both professional programmers with good math skills and beginners in the computer programming field writing their first number-guessing C++ game. Recipes on gathering entropy and access to standard Windows/Unix APIs for random number generation are of great practical use. The application tampering chapter was probably the most informative thing for me - great collection of information, rarely found in other application or network security publications. How do you protect against software piracy by using checksums? How much time should you dedicate to software protection? What is the theory behind code obfuscation? How do you hide ASCII strings in data segment? How do you detect modern debuggers? The answers to such questions are usually fragmentary and are usually considered either intellectual property of the company or belong to a 'warez' site, where the quality of sources is questionable.

Is the Book Useful? This book is a great resource for quick look-up of readily available solution (I've read it online on Safari, so I cannot vouch for the usability of the paper edition when searching for information). I've written a Master's thesis on this topic (although my actual topic was way more narrow than the scope of this book) and still found a lot of great information. If you've never seen C/C++ code or feel uncomfortable with Unix/Windows API programming, you will probably find the Cookbook overly technical. A higher-level application security text is available for those new to the subject (besides the Building Secure Software title mentioned above, there's a great title called Writing Secure Code from Microsoft), while this book gets into dirty, nitty-gritty details.

Yeah, everyone and his brother knows how to implement a symmetric encryption algorithm, but how do you actually do it without compromising the system and introducing new possible loopholes? The cookbook answers questions like that, and, as mentioned above, provides detailed overview of programming strategies for the two most popular platforms. Taking the cookbook concept further, this book teaches you how to make a basic ham-and-cheese sandwich as well as fine cuisine. Too often the code measures for basic security and preventing buffer overflows are summarized in higher-level concepts, thus allowing the developers to make errors even with the most trivial applications. If you're a professional programmer and do not get tired by looking at sometimes profuse code examples, this book would probably be a good read from the beginning to the end. If C/C++ is not your preferred area, the usefulness of this title decreases severely, however, it might serve as a good reference.

You can purchase Secure Programming Cookbook for C and C++ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

are you kidding?

[geekoid]

there are too many people in catagory 1 that think they are in catagory 4.

funny enough, if there code was a hurricane, it would be at least a catagory 4.

A fifth type of programmer...

[cperciva]

There is a fifth type of programmer, not covered by the categorization mentioned above: Those who really understand the language, the machine architecture, software engineering, and the application area, and who write code which is absolutely antithetical to anything you'd find in a textbook.

I, for example, severely abuse short-circuit evaluation -- I'll often put five or more function calls into an if() conditional, ||ing their error conditions together -- but there's nothing wrong with that; you'll never find it in a textbook, but once you're used to reading that sort of code, it is more compact, easy to understand, and easy to maintain than the alternatives.

This looks like a nice text

[PureFiction]

I read the sample chapter and the table of contents, and this certainly looks like a very useful book for developers.

The random number generation chapter is excellent. Many people overlook this necessity in cryptographic applications unaware that flaws introduced by insecurely random (i.e. predictable) enrtropy sources can render the best PKI, ciphers and authentication mechanisms crippled.

One of the reasons I tend to drool over VIA hardware is that their MiniITX EPIA systems have support for hardware entropy on the CPU via the Nehemiah core, which is also available for a wide variety of OEM/embedded applications.

This means you can use a highly secure entropy source (/dev/hw_random in linux for example) for all of your cryptographic applications, from GPG to ssh to the linux kernel itself (IPSEC). And best of all, you never have to worry about the entropy pool blocking, or reverting to less secure PRNG like /dev/urandom. ... I wonder if this book is out on Safari yet.

Re:Secure Programming for Ruby and Intercal

[viega]

We stick to a C77 subset where possible that works across both C and C++ programs. There are some C++-specific examples for C++-specific issues.

Mostly, the security-critical problems DO overlap, unlike your statement. C++ doesn't have massive problems with stack overflows the way C does, but trades it off for big problems in heap overflows (due to leaving all those function pointers around on the stack).

Anyway, go read the book and come up with a VALID complaint, please.

Re:Anyone want to chip in...

[viega]

I sent at least one person there a free copy ;-)

Honestly, they've got some smart people in this space, there. They've really been making a large effort, and it takes time for stuff like that to pay off, particularly when they've got dozens of millions of lines of legacy code written before their big security push. That is, while they might have started to care about security late in the game, they're currently putting forward a huge effort. I'll reserve judgment until some unspecified future date.

Re:Write Secure Code: a summary

[Xugumad]

Other things, just what I can remember at the moment, anyone want to remind me of what I've missed:

• Program defensively. Don't just perform the bare minimum of checks required to make your system work, perform double, triple or even more checks where feasible.
• Remember to encode all text correctly. This is particularly important in cases such as shell commands or SQL statements. Be careful of odd examples where multi-layered encoding is required (Javascript in HTML being a good example).
• Never use data from the user without sanity checking it. Feel free to strip characters that aren't there ("../" in a file's name, rather than path, for example).
• When calling external programs, use their full path. Nothing's quite as annoying as some smart ass placing an identically named file higher up the search path, that executes "rm -rf /".
• Do not assume that because you can't figure out how to crack a cryptographic method, it's secure. Get a mathmatician, or even better a cryptoanalyst, to check it for you.
• Security through obscurity gets a bad rep. It's a hell of a lot better than nothing, but never rely on it except where necessary (passwords are a good example of where it's necessary).