> 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