On Mon, 13 Jan 2003, David Wheeler wrote:
> But, I think there's a middle ground that applies to most products:
> train the developers so that they're no longer unskilled. Instead,
> developers should be trained so that they're at least basically skilled,
> and so they know when they need the experts.
>
> Most of the vulnerabilities currently being found in software aren't
> from some exotic attack or approach. They're from well-known
> attacks, based on common mistakes made by developers, and there are
> already-known approaches that completely counter them.
> The problem is that the DEVELOPERS don't know about them.
> If developers avoided these mistakes, we'd eliminate the "easy" attacks,
> making their software much harder to attack. That wouldn't make the software
> "invincible", but it would raise the bar significantly.
>
> Not everyone is willing to pay to develop software that can, on its own,
> defend against a sustained attack by a foreign government. But it's
> reasonable to expect that developers will produce software that resists
> unskilled 13-year-olds who have a little spare time. I think that's the
> goal we should set: _more_ secure software, not perfectly secure.
>
> Although geniuses are in short supply, we have a greater supply of people
> who can follow guidance... once they know that guidance.
> Once you do this, other evaluation techniques become more effective too.
I once worked as a consultant for a large company that asked me to help
make some of their in-house application code more efficient. While they
had a few really sharp people working for them, as a group, they made some
fairly entertaining mistakes. I'll explain a couple of my favorites, and
while I do so, perhaps you can think of how we might explain to these
folks how to avoid buffer overruns and all the other classic, well known
exploitable errors that we need to stay away from to write secure code.
First, one of their programmers had to generate a list of structures to
hold some data, but he didn't know how many of these structures he needed
at compile time, so at run time he determined how many structures there
were (we'll call that number "N"), and allocated an array of pointers to
structures long enough to hold N pointers. He did that with a statement
like:
sPList = (struct s **) malloc(N * sizeof(struct s *));
Then for each structure he allocated space with a statement like:
sPList[i] = (struct s *) malloc(N * sizeof(struct s));
He allocated enough space for N^2 structures, rather than just N
structures as he intended, and I never really got the sense that
he understood what I was telling him when I explained the problem.
Second, they ended up, within many of the C programs, needing to count
the number of lines contained in various files. The most common way they
accomplished this counting went something like:
system("wc somefile.txt > /tmp/wc.output");
wcoutFILE = fopen("/tmp/wc.output","r");
if (fscanf(wcoutFILE,"%d",&count) != 1) {
fprintf(stderr,"can't count lines in somefile.txt\n");
exit(1);
}
fclose(wcoutFILE);
Needless to say, this is not the most efficient way to could lines in
a file from a C program.
It is important to note that the company in question saved a great deal
of money by using these inefficient programs to replace manual labor
for doing the tasks they were designed to perform. As much as you and
I might wish all programmers were clueful enough to avoid constructs
such as these, the fact is that the number of programmers who have a
very shallow understanding of what they are doing but still accomplish
quite enough to justify a salary is much larger than the number of
programmers that have a really deep understanding of what they are
doing.
I believe it is unrealistic to expect industry to stop using programmers
with a shallow understanding of the work they do. At the same time, I
think that, in the absense of a moderately deep understanding of
programming, no set of simple programming guidelines or advice will help
the programmers who display their shallow understanding with code like
the above avoid making easily exploitable mistakes.
I think those of you who are looking for such guidelines are
underestimating just how clueless a programmer can be and still do work
that helps his employer save a great deal of money.
my $.02
Adrian
This archive was generated by hypermail 2b30 : Mon Jan 13 2003 - 09:13:04 PST