Re: Standards for developing secure software

From: David Wheeler (dwheelerat_private)
Date: Mon Jan 27 2003 - 08:04:59 PST

  • Next message: Pavel Kankovsky: "Re: Standards for developing secure software"

    > Subject: RE: Standards for developing secure software
    > From: "Witness" <bmeyer67at_private>
    > Date: Tue, 21 Jan 2003 01:41:55 -0500
    ...
    >>"Steven M. Christey" wrote:
    >>
    >>>David Wheeler said:
    >>>
    >>>>The problem is that developers don't grok _ANY_ of the books.
    >>>>
    >>>I wonder if some of this has to do with how the books are laid out.
    >>>
    >>I doubt thatīs the main reason.
    >>
    > 
    > It may not be the main reason, but it could be a very big one.  I'm a
    > slow reader and as such I don't have much time to actually read most
    > books. Instead, I keep books around and use them mainly for a reference.
    > If I'm looking something up, it's on how it would be useful to me at
    > that moment.  E.g I wouldn't be looking up "How to prevent a buffer
    > overflow" but rather "strcpy()" or "strncpy()".  Thus, if the book is
    > more oriented towards what I am doing and give ideas under that topic on
    > how to prevent other issues (like a buffer overflow) then I would be
    > more likely to come across the topic.
    
    
    I certainly agree that it's helpful to have information on common bugs
    organized by the function that uses them.  But when you CAN include such
    information, it shouldn't just be in a separate "security book" - that
    material should be in whatever reference the programmer NORMALLY uses
    for learning about those functions.  Indeed, Unix man pages often do so.
    If you take a Linux system and type "man 7 man", you'll find that on Linux
    there's even a convention for recording this information in man pages
    (in a SECURITY section).
    
    The manual page for strcpy on Red Hat Linux 7.2 even has some security info:
            If the destination string  of  a  strcpy()  is  not  large
            enough  (that  is,  if the programmer was stupid/lazy, and
            failed to check the size  before  copying)  then  anything
            might  happen.   Overflowing  fixed  length  strings  is a
            favourite cracker technique.
    
    But in the long run this is hopeless; this might be an overflow too,
    without ANY function getting called:
         while (*s++ = *c++) {}
    
    Other languages may not normally have buffer overflows, but there are
    many other problems.
    
    While I support adding security information into manuals, the ability
    to write secure programs requires knowing more GENERALLY how to do so.
    Not just "here are the 3 dangerous functions" - that won't deal with
    buffer overflows in C, cross-site scripting, failing to do input checks, etc.
    Thus, we still need to train developers how to develop secure
    code regardless of language, and then train developers on the
    quirks of the languages they currently use.
    
    
    
    >>I deal with leading programmers, and it seems to me that they are very
    >>well trained to always think about performance in terms of memory and
    >>CPU
    >>usage. They rarely never are trained to think about security from line
    >>one.
    >>
    > 
    > I'm just graduating college this year, but I've been programming for
    > about 6 or 7 years. I'm still more oriented towards CPU and memory, and
    > I believe that programmers should always be worried about CPU and
    > memory.
    
    
    Programmers should always be _engineers_. They should be working
    to _solve problems_, by identifying the problem to be solved and how to
    best meet all constaints on its solution.
    
    They should always make sure that their solutions result in acceptable
    CPU and memory usage, but there are many other constraints too.
    How long will it take to develop? Maintain?  Will others be able
    to maintain it? Will it be secure?  Clearly, a CPU/memory hog can be
    a serious problem, but so are programs that take twice as much time to
    write.  What trade is "best" depends on the constraints.
    
    Clearly, there are cases where CPU and memory usage are especially
    important, and others where they are less so.  What we need are programmers
    who understand the trade-offs, know multiple tools, and can understand
    how to trade the right tool for the problems.
    



    This archive was generated by hypermail 2b30 : Mon Jan 27 2003 - 09:37:07 PST