Re: Standards for developing secure software

• Previous message: George Dinwiddie: "Re: Standards for developing secure software"
• Maybe in reply to: David Wheeler: "Standards for developing secure software"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 27 Jan 2003 11:04:59 -0500
From: David Wheeler <dwheeler@ida.org>
To: secprog@securityfocus.com

> Subject: RE: Standards for developing secure software
> From: "Witness" <bmeyer67@calvin.edu>
> 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.

• Next message: Pavel Kankovsky: "Re: Standards for developing secure software"
• Previous message: George Dinwiddie: "Re: Standards for developing secure software"
• Maybe in reply to: David Wheeler: "Standards for developing secure software"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]