Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Books Media Programming Book Reviews IT Technology

Secure Programming Cookbook for C and C++ 159

Posted by timothy from the eye-of-newt dept.
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.
This discussion has been archived. No new comments can be posted.

Secure Programming Cookbook for C and C++ More

Secure Programming Cookbook for C and C++

Comments Filter:

  • Maybe they should send one copy to... (Score:4, Funny)

    by ospirata ( 565063 ) on Wednesday October 08, 2003 @12:17PM (#7164828)
    I would send a free copy to openssl staff
  • Don't use system(), and be careful with buffers.

  • NEWSFLASH! Never before! (Score:2, Funny)

    by Anonymous Coward
    Headline: Previous Knowledge Required Before Reading Technical Book

    Film at 11.
    • for those of you with MCSE certification, please be advised that does not count as "Previous Knowledge."

      The same goes for "learning facilitaters" employed in the public school system.

  • Here's how to write safe C code (Score:5, Funny)

    by Anonymous Coward on Wednesday October 08, 2003 @12:22PM (#7164905)
    int main(void)
    {
    system("python mainapp.py");
    return 0;
    }

    • For all the idiots who think you're right... (Score:5, Informative)

      by Anonymous Coward on Wednesday October 08, 2003 @01:17PM (#7165270)
      How much does the programming language matter?
      Posted by John Viega on Mon, Sep 15, 2003 (07:59 AM) GMT

      We've now been slashdotted. After lowering the idle connection timeout from hours to minutes, we're doing fine (famous last words). The comments are full of "C sucks" rants. I thought I'd summarize a few of my thoughts on this issue.

      Yes, C and C++ have special "features" that make adding security problems easy, even for a fairly informed and careful developer. That's impossible to deny, though the book and this site do cover mitigation strategies that can make a big difference. However, people are miscalculating by assuming that just switching to another programming language is going to make a big difference. It can make a difference, but not as big of one as people are expecting. Defensive practices can offset the problem.

      We've done a few case studies on number of defects per line of code when performing code audits. C and C++ programs have averaged 4-5 security-critical defects per thousand lines of code. Java programs still average 1-2 security-critical defect per thousand lines.

      There are plenty of problems that programming languages themselves haven't fixed. And, honestly, most of those problems should be fixed at the API level. For example, it's stupid that neither OpenSSL or Microsoft supports full certificate validation by default. The programmer has to know what security checks to perform and write the code to do them manually, instead of getting "secure by default" behavior. As a result, most applications that use SSL/TLS are vulnerable to man-in-the-middle attacks. Sure, this is a problem in some common C-based libraries, but it's just as common in the SSL implementations for other languages. Other problems such as cross-site-scripting and SQL injection affect other languages far more commonly than C and C++, since those languages aren't often used in web apps.

      In C and C++, the common security problems are relatively easy to understand, and if you are diligent and take the right preventative measures, they're not so hard to avoid. In other languages, the easy/obvious problems don't apply, but as people use high-level primitives to build complex applications, they tend to introduce complex security problems (race conditions in servlets can be quite tough to identify, and still have security implications).

      In short, you aren't likely to accidentally end up with a "secure" program, no matter which programming language you use. We're currently working on a Java Secure Programming Cookbook, and are assembling a team for a PHP Secure Programming Cookbook. There's plenty of material for both books, without question. Expect both to be at least 400 pages, without even covering all of the low-level cryptographic stuff we cover in the C/C++ version.

      At the end of the day, if you're going to be diligent, then security can be reduced to a fairly minor consideration in programming language choice.

      One final note: C++ is often perceived as being more secure than C, because it has an abstracted string type. That's not really true, even ignoring the few cases where you can still overflow using C++ strings. Basically, heap overflows are far more dangerous in C++, because lots of function pointers tend to be stored on the heap, due to the way classes and exception handling is implemented (the GOT is stored on the heap even in C programs, but C++ programs tend to have function pointers coming out of the wazoo). If an attacker can overwrite one of those pointers, then it's often possible that he can replace it with a pointer to some sort of malicious payload.

      • There was another story about this same book on Slashdot a few weeks ago. I made a snide remark about the risk amplificiation inherent in writing "secure" code in C/C++ rather than a language that disallows illegal memory operations.

        John Viega took me to task, wielding the old "you can write insecure code in any language" argument. That's true, but it's beside the point. C and C++ inherently increase the risk of security problems because they don't check buffer bounds, so the program ends up with all o

        • Re:For all the idiots who think you're right... (Score:5, Insightful)

          by viega ( 564643 ) <viega@lis[ ]rg ['t.o' in gap]> on Wednesday October 08, 2003 @02:08PM (#7165640) Homepage
          No, I said you MISSED my point. Of course it's easier to write more secure code in other languages. There are better choices than C and C++ for most tasks. What I was arguing is that if you rely on C and C++ sucking as a crutch, then your programs are going to have security vulnerabilities in other languages, too.

          That said, something like 20% of the code out there is written in C and C++ to this day, and that's not dropping off slowly. We did this book first because there's a market for it and because it's got all the low-level solutions people can use as a foundation in any language. Next up is Java...
        • C and C++ inherently increase the risk of security problems because they don't check buffer bounds, so the program ends up with all of the security problems that would've existed in a buffer-safe langauge, plus buffer overflow vulnerabilities.

          I want to know why the language should check for buffer bounds. I think a class system should do this. I think a class system knows (or can know) what the memory is for, or at least the pattern of it's usage, and these are assumptions you do not want to make at th
      • We've done a few case studies on number of defects per line of code when performing code audits. C and C++ programs have averaged 4-5 security-critical defects per thousand lines of code. Java programs still average 1-2 security-critical defect per thousand lines.

        [...]

        At the end of the day, if you're going to be diligent, then security can be reduced to a fairly minor consideration in programming language choice.

        You can cut security-critical defects by 50%, and that's a minor consideration?!
      • "4-5 security defects per thousand lines vs 1-2 security defects per thousand lines."

        How many lines of C/C++ is needed compared to other languages?

        Impact of security defect is different. Often with C/C++ the attacker gets to run arbitrary code of own _creation_. With sane languages typically the only easy way to run arbitrary code is with SQL injection, or interaction with a C/C++ program. This to me is a very important difference.

        Ease of avoidance/fix is different. Seems only very few people can code se

    • I hope this isn't setuid/setgid - because if it is there's a massive security hole.

      Because you don't supply absolute paths to either 'python' or the script to execute a malicious local user could set their path to /tmp, and stick a script called "python" in ther.

      Instant privilege escalation ..

    • Am I the only one amazed that a 5-line C fragment (granted, written by AC) has what could be a critical flaws? If mainapp.py fails, app.c still returns zero, so the higher context won't ever see the error. Also, the command line isn't passed to python. Picture this: "nukecontrol --disarm && launchcontrol --fire". Nukecontrol returns -1 because it needs arguments, but the missile is launched anyway.

  • are you kidding? (Score:5, Interesting)

    by geekoid ( 135745 ) <dadinportland@ y a h o o . c om> on Wednesday October 08, 2003 @12:22PM (#7164909) Homepage Journal
    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.
    • if there code was a hurricane,

      i hope you dont code the way you write --
      their code

      maybe you're the reason why I keep on getting those damn out of memory errors...
      calling the wrong memory reference....
    • if there code was a hurricane, it would be at least a catagory 4.

      Actually, a hurricane is a pretty highly-organized weather system. I'm not sure this analogy works all the way through.

  • I don't need this (Score:4, Funny)

    by deltagreen ( 522610 ) on Wednesday October 08, 2003 @12:22PM (#7164915) Homepage
    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.

    Well, I don't need this, since I'm in category 4. Instead of reading this nonsense, I'll go finish my Visual Basic project.

  • #0 Those who can't write code worth crap, but keep thinking that they can.


    Too damned many of them.


    -bofh

  • A fifth type of programmer... (Score:5, Interesting)

    by cperciva ( 102828 ) on Wednesday October 08, 2003 @12:28PM (#7164980) Homepage
    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.

    • Re:A fifth type of programmer... (Score:1)

      by Anonymous Coward
      "I ... severely abuse short-circuit evaluation"

      I want to tattoo that on my forehead.
    • I agree. I'm not sure what "textbook" code means. There are plenty of textbooks out there that have, as examples, bone-chilling examples of C++ code, and a few of those are produced by O'Reilly (see "Practical C++ Programming"). In fact, a great deal of the code I see produced by other programmers is very reasonable and tight, but isn't something I would see in a textbook at all. I think it's possible that this book author has revealed a bias toward the code of book authors ...
    • There's nothing wrong with that!

      Unless, of course, you are thinking about code {maintenance, reusability, readability}. But real programmers don't worry about that, right?

    • Re:A fifth type of programmer... (Score:5, Insightful)

      by rvaniwaa ( 136502 ) on Wednesday October 08, 2003 @12:54PM (#7165211) Homepage
      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.

      There is nothing wrong with that as long as the persons who are going to maintain the code are also of the fifth type of programmer. Generally, the people maintaining your code are of the second type and this code is going to confuse the hell out of them

      We had a guy on our project that wrote an if statement that had three levels of embedded ?: operators along with several function calls, several of which took parameters that were generated by ?: operators with other function calls within them. There were half a dozed each of ||, && and ! along with a few |'s and &'s thrown in for good measure.

      Yes, it was the most optimal code for this situation. However, this situation did not require that level of optimization and, when I had to fix it 2 years later because of a subtle bug that could have been obvious, I was ready to ?: the guy that wrote that code!

      • Yes, it was the most optimal code for this situation.

        This code may have been optimal if the only measure was lines of code but that doesn't mean it would have executed any faster. Having fewer lines of code doesn't necessarily lead to better performance. Additionally, it can (and did in this case) lead to problems maintaining the code.

        • Yes, it was the most optimal code for this situation.

          This code may have been optimal if the only measure was lines of code but that doesn't mean it would have executed any faster. Having fewer lines of code doesn't necessarily lead to better performance. Additionally, it can (and did in this case) lead to problems maintaining the code.

          Believe it or not, it actually was faster. I checked the assember after I unraveled all of the convoluted crap that he had done and the unoptimized assember was a few sta

          • believe me, comparing the debug assembler is not a big deal - you either run the debug code, with its additional instructions embedded in it, stack checks etc etc, or you run nice optimised release build code.

            Comparing what the plonker wrote with the debug code is not a big deal - I think I can guarantee the release build is faster, even if the if statements were unravelled. So the compiler is better than your example programmer. In fact, if the debug version is only slightly slower than him, he hasn't exa
            • >>I read a while back that you shouldn't try to optimise code to such a low level - the compiler will always do a better job of it than you can. Not only that but the time saved in maintenance is significantly greater than any time saving.

              Reminds me of Deep C Secrets. Always loved that title (esp with the 'extinct' fish on the cover).

            • believe me, comparing the debug assembler is not a big deal - you either run the debug code, with its additional instructions embedded in it, stack checks etc etc, or you run nice optimised release build code.

              Comparing what the plonker wrote with the debug code is not a big deal - I think I can guarantee the release build is faster

              That would be the case except the release code is generally the code with debug... It is an odd situation but, for various reasons, we run the debug code for our release.

              I

      • "There is nothing wrong with that as long as the persons who are going to maintain the code are also of the fifth type of programmer."

        I totally agree with this. But how many of us code just for ourselves and don't care about anyone else understanding it? How many of us use programming as a method of creativity, and express our code in the very best manner known to us, and not the best manner known to the general public?

        Is it much different in a corporate setting? Same ends, yet perhaps slightly different

    • Isn't this fifth type usually known as a "Perl Munger"?

    • heh. (Score:2)

      by pb ( 1020 )
      Ever take a look at the original code for the Bourne shell, for example? It looks like... a big shell script. Why? Well, due to a *lot* of #define abuse. It's quite scary.
    • Debugging is twice as difficult as coding. If you write the code as cleverly as you possibly can, then you are - by definition - not smart enough to debug it.


      Kernighan and Pike


      Learn it, live it.

    • 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;

      Unless of course you care about the order in which they are called. Note that the C spec says that there is a sequence point after each conditional however,
      the order in which conditionals in an || are evaluated is not defined in the standard, as in, there is no sequence point there. so in a statement such as:

      if((Do_Something())
      ||(Do_Something_Else()))
      {
      • Note that the C spec says that there is a sequence point after each conditional however,
        the order in which conditionals in an || are evaluated is not defined in the standard, as in, there is no sequence point there.

        You must have a different copy of the C standard. My copy reads "Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares unequal to 0, the second operand is not eval
      • Yeah, but isn't || defined to evaluate left to right? It is still an operator and you could do

        int main()
        {
        int n = 5 || 0;
        printf("%i\n", n);
        return 0;
        }

        which outputs, logically, "1".
      • Not so fast! There may not be a sequence point there but the standard explicity says the left operand of the logical OR operator is evaluated first and only if the result is zero is the right operand evaluated. The logical AND operator is similar. If the left hand expression is false, the right hand expression is never evaulated. Most operators aren't like these two; instead the order of evaluation is not specified. The logical AND and OR operators are unique in this respect.
    • Your fifth type of programmer fits in either the third or fourth category.

      3. Those who write good code most of the time, but who don't fully realize their limitations
      If you write code that is difficult to maintain for the fun of having written it, you belong in the category of those who should be limited. Let another programmer review your code before it is committed. If any line takes more than a minute to understand, he either rewrites it or passes it back.

      4. Those who really understand the languag

      • This is the same code, but the latter is more understandable.
        You have got to be kidding me!!! There are many good reasons to comment code and many bad reasons. Check out the book "Code Complete" if you want a good discussion of this. The *WORST* type of comment is the kind that mindlessly repeats what any fool can see that the code does. E.g.:

        x--; // decrement x
        if (x 0) // check if x is less than 0
        return 3; // return 3 if x is less than 0.

        That is pretty much exactly what your "good" version does.
        • To the ACs who noticed that they should have been &&s, not ||s, you are correct.

          About the lousy comments, you are also correct. Some of my code does look like this, because I would start by writing an English version, comment it out, and then insert code. The redundant comments get removed as time passes and the code is revised. My comments tend to focus on the business reasons, with a few to explain more complicated code or to warn about possible failures. I agree that "Code Complete" is a go
    1. It was not typeset with TeX (a secure program if ever there was one!)
    2. The authors don't advocate the use of literate programming, which is proven to produce more secure code
    3. The authors use "C" and "C++", rather than focusing on concepts via a virtual machine like MIX.

  • Hard to sell (Score:4, Funny)

    by gusmao ( 712388 ) on Wednesday October 08, 2003 @12:30PM (#7165004)
    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

    People who think they are in category 4 wont buy the book, because they belive they dont need it. So who is the target audience anyway? :-)
  • there's a great title called Writing Secure Code from Microsoft

    Is this supposed to be some kind of joke?

    • Very funny, of course.

      But the Howard/LeBlanc is well worth a read. Viega and Messier's book is also extremely useful, and I for one am grateful that they stuck to the Win32 API.

    • Buy one and read it (Score:3, Informative)

      by melted ( 227442 )
      You'll be surprised. Guess what, the guy who wrote the book really knows how to write secure code, and the book really teaches you a lot without offering many pre-cooked examples. This is a good thing. Helps you code with security in mind.
    • Jokes aside (and you stole mine, I was going to write my own version of it:

      Great oxymorons:
      • Jumbo shrimp
      • Millitary intelligencse
      • BASIC
      • Utah Jazz
      • Writing Secure Code from Microsoft

      BASIC gets a nod because it's the only single word good oxymoron [xemacs.org] I know

      Anyways, Microsoft hires some very talented guys. A lot of their problems are marketing related. "Hey, we need to ship, I don't care how much QA you've used". Or even worse "we need to get the whole world integrated, everything shares code with everyt

    • yeah, so. Its not an oxymoron really - even if they don't follow what they preach throughout the codebase.

      Check out what they say:
      http://msdn.microsoft.com/msdnmag/issues/02 / 09/sec uritytips/default.aspx

      How about this one.. integer manipulation vulnerabilities.. not just MS code at fault here either:
      http://msdn.microsoft.com/security/secure code/colu mns/default.aspx?pull=/library/en-us/dncode/html/s ecure04102003.asp

      plenty more on the MS site.

  • Categories ... (Score:5, Insightful)

    by Chromodromic ( 668389 ) on Wednesday October 08, 2003 @12:35PM (#7165045)
    There are 4 types of programming book authors:

    1. Those who categorize programmers artificially for the sake of a point.

    2. Those who categorize programmers incorrectly because they don't know better, but for good reason.

    3. Those who categorize programmers because they figure that, by doing so, they will establish themselves as an authority on ranges and types of programming skill.

    4. Those who avoid categorizing programmers because they realize that it's kind of goofy to do so.

    Everyone knows that there are folks out there that can do their job better than others. But do those categories really exist? It may seem like I'm picking nits, but is there really a class of programmers that writes buggy code almost all of the time? I mean, I suppose there is, but it doesn't seem to me like they'll have a long career in software ...

    • Another reason to categorize (Score:4, Insightful)

      by niom ( 638987 ) on Wednesday October 08, 2003 @02:00PM (#7165593)

      Marketing.

      People are more likely to buy a product if they think it's specifically designed for them. Those four categories serve that purpose.

      Please observe how the description of the third category has been made as broad as it can be. Basically the author is saying that the book is not targeted at you if you are the worst programmer in the world, not a programmer, or Donald Knuth. Such an asymmetric categorization can only be for marketing purposes.

    • I disagree. On a somewhat more technical leve, I read his four categories as something like this:
      1. Those who use gets(), and call functions like open() without checking the return value, knowing it could bite them in the ass but thinking that nobody will notice,
      2. Those who get some of the obvious stuff (like not using gets()), but often miss other things which should be known, and often opt for less elegant techniques because they haven't read/written enough code to know what better techniques are out there
      • I'm unclear here -- are you just fond of complaining, or do you have a legitimate suggestion for the author to integrate into possible future editions?

        I appreciated your post, with exceptions, right up to the point where you decided to be yet another geekoid asswipe, making some sneering little point while winding tape around your glasses. I reject the notion that because an author wrote a book it's our obligation here to all be constructively helping to better his work. There are enough computer books in

        • Hah!

          Nice response ;)

          I agree with category 4 being bull -- as I implied, and you stated, textbook code is usually about as far from secure as you can get.

          And I don't have tape around my glasses, nor do I have a pocket protector. And I definitely agree that just because some guy wrote a book doesn't mean he's not a jackass.

          At the least, the review basically sucked. I'd probably have gotten more information from a link directly to Amazon.

  • Alternative Review (Score:2, Informative)

    by Sir Haxalot ( 693401 )
    Password sniffing, spoofing, buffer overflows, and denial of service: these are only a few of the attacks on today's computer systems and networks. At the root of this epidemic is poorly written, poorly tested, and insecure code that puts everyone at risk. Clearly, today's developers need help figuring out how to write code that attackers won't be able to exploit. But writing such code is surprisingly difficult.

    Secure Programming Cookbook for C and C++ is an important new resource for developers serious ab

  • This looks like a nice text (Score:5, Interesting)

    by PureFiction ( 10256 ) on Wednesday October 08, 2003 @12:40PM (#7165101)
    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.
    • Comment removed based on user account deletion
      • Like the Intel i815 chipset?

        To be fair I should have mentioned the hardware entropy solutions that both Intel (i810, i815, etc) and AMD (76x boards) have available, but they are much smaller offerings in Intel and AMD's product line. Contrast this with VIA which is making the Nehemiah core a centerpiece of existing EPIA boards, like the M10k, and forthcoming boards like the M2.
    • You know that not even noise diodes are secure to attacks? Even a simple lighted match (i.e. heat) near such a diode can severely influence the quality of the generated random numbers.

  • Useful (Score:2, Funny)

    by KentoNET ( 465732 )
    "a book which he says is useful -- but only if you have the background to use it"

    So, uhh...it's useful, but only if you can use it...
  • And it's the perfect holiday gift for that special Microsoft Programmer you know and love!

  • You know, I just might read this... (Score:5, Insightful)

    by pVoid ( 607584 ) on Wednesday October 08, 2003 @12:49PM (#7165173)
    This is the first slashdot book review that I've seen in a long time that I'm seriously considering buying.

    I'll tell it out loud flatly, the reason is because it's not a "my system is better then your system" kind of book from what it seems. Those are the books that annoy me the most "Well, you see, you could be using ASP, but then your app would be WAAAAAY more insecure."

    On top of that, actually seeing equivalents of the same code on both system families will be a nice intro to some, including me, for equivalent APIs that we didn't know existed in other systems.

    Btw, the Secure Coding book by microsoft is really good too (very few actual API references, so it's not really microsoft platform targeted).

  • ....can be found here [purdue.edu]. My favorite:

    "You're proposing to build a box with a light on top of it. The light is supposed to go off when you carry the box into a room that has a Unicorn in it. How do you show that it works?"
  • People that can write good clean code, comments, and documentation. Not too many of those around!

  • Thanks! (Score:5, Insightful)

    by viega ( 564643 ) <viega@lis[ ]rg ['t.o' in gap]> on Wednesday October 08, 2003 @01:32PM (#7165377) Homepage
    Thanks for the good review. A few minor points:

    1) All of the book's code is available on our web site. The web site is probably the right place to go to to get the code, just because we can update it when there are errata (and you don't have to copy it out manually if you want to use it).

    2) This is an implementation-focused book. You're right to refer to other texts for architecture, and besides my other book, the Microsoft press book you recommend and David Wheeler's free online HOWTO are both excellent (though I personally think the O'Reilly entry into that space is poor). At the same time, we do end up covering many aspects of good architecture in the discussion. Providing the context for a good implementation requires an understanding of the architectural issues, at least to some degree.

    3) We have had several people tell us that they find the book very useful for other languages as well. I think it covers a lot of low-level implementation stuff that isn't available in other books, and is useful as long as you can READ C code. If there's anything people want to see for other languages, etc., feel free to send us email suggesting it. We will have frequent updates to this web site with new content (at least monthly). Much of the content will be for other languages.
    • I bought a copy of the Building Secure Software book, and it wasn't a bad read -- but the one flaw I did see was the code examples, which had too many correctness issues to be considered secure. The first rule of writing secure code in C or C++ is to avoid reliance on undocumented behaviour. "void main" is a nonstandard extension, casting from a char* to an int* without knowing if the alignment is suitable is undefined behaviour, and so on. Unfortunately I don't have my review notes from this book with m
      • Everything in the Secure Programming Cookbook compiled without warning under gcc -Wall and the Visual Studio compiler (where appropriate) and received a reasonable amount of functionality testing. We tried pretty hard to get people to do third-party testing, but it's very hard to get people to agree to test so much code. So it's very likely that there are some functionality bugs, but as they're found, we update things on the web site. This is why when using the code, you should get the newest code base f
  • Why do people keep writing books about "C/C++", or keep referring to it as if there was such a programming language? They are two, distinct languages with radically different problems and very different styles, used mostly for very different things by disjoint programmer communities. They have less in common than Java and C#.

    And don't argue that C is a subset of C++ - is isn't. It never really was (look at the output of "printf("%d", sizeof('x'));" for a start, never mind "#include <string.h>" vs. "

    • 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.
      • Looking at the table of contents, I'd mostly agree with your assessment, however...

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

        What?
        Are you talking about vtables of stack allocated objects? Because aside from that I don't see how a typical c++ program would have more function pointers on the stack than a typical C program. Furthermore, what does that h
  • to help me buy a copy for Microsoft?

    • Re:Anyone want to chip in... (Score:4, Interesting)

      by viega ( 564643 ) <viega@lis[ ]rg ['t.o' in gap]> on Wednesday October 08, 2003 @03:08PM (#7165861) Homepage
      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.

  • Please (Score:2, Funny)

    by bluyonder ( 643628 )

    Somebody send a copy to Microsoft...

  • Comment removed based on user account deletion
  • This is mostly me talking out of my ass. I never really formally studied any of these topics, just some stream of consciousness stuff that I thought of last time our workplace went down from Blaster.

    I was at lunch recently with a friend who happens to work with me. We talked about the Von Neumann programming model. Any code that runs on a current processor ends up being put into a finite state Von Neumann machine. Machines have gotten so complex now, with so many services exposed, that though it's in t
    • Here's one from my stream of consciousness:

      Don't drink too much beer before peeing in your stream of consciousness...

      As for the talking out of ass thing... Go figure ;)

Slashdot Top Deals

Them as has, gets.

Close