Slashdot Mirror

← Back to Stories (view on slashdot.org)

Secure Programming

Posted by michael on from the self-promotion dept.

viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."

3 of 360 comments (clear)

  1. Secure programming FAQ by SystematicPsycho · · Score: 5, Informative

    Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
    Securing Programming FAQ
    --

    --
    Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
    1. Re:Secure programming FAQ by viega · · Score: 5, Informative

      This is not a very good (modern) guide. There are plenty of better guides (still free) to which we link on the web site, such as David Wheeler's HOWTO . The book is more about giving actual code examples on how to do things properly. And, oddly enough, all the code is also available for free on the web site.

  2. Re:We really need a different language by slamb · · Score: 5, Informative
    qmail and djbdns do not have security holes.

    Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.

    They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.

    No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:

    A stralloc structure has three components: sa.s is a pointer to the first byte of the string, or 0 if space is not allocated; sa.len is the number of bytes in the string, or undefined if space is not allocated; sa.a is the number of bytes allocated for the string, or undefined if space is not allocated. A stralloc variable should be initialized to {0}, meaning unallocated.

    Applications are expected to use sa.s and sa.len directly.

    If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.

    It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.

    But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.