L. Adrian Griffis wrote:
> 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.
>>
...
> 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.
...
> 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.
Okay, so he allocated too much memory, but that's probably not seriously
security-relevant. It might allow a DoS attack, but unless it limits
data size, it just crashes at the sqrt(max size).
>
> 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.
If this is the "worse you've seen", consider yourself lucky.
Let's presume that the most important resource to be optimized is
development time, not execution time. That's true for many in-house
projects. In that case, this is actually well-optimized for the
resource that is actually scarce. Besides, "wc" is probably highly optimized,
so it probably runs better than you think it does... so this is probably
not too bad, even in execution time.
I actually tend to NOT use C if unneeded; instead, I'll prefer a language like
Python or perl or shell, and then call down to built-in programs like "wc".
Such an approach is even _less_ efficient in cycle time, but the code can be
written more quickly. It's quite likely that the real mistake
in your example is that they're using C at all, in a situation where
it's a poor fit for the problem.
The real problem is the /tmp use, if /tmp can be accessed by attackers.
Now you have a real security problem. But guess what? Existing security
guidelines could have helped them there.
> 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.
It all depends on your expectations. A shallow programmer, with a bunch
of guidelines, will still make terrible mistakes. But they'll probably
make FEWER of them. Which makes the attacker's job harder.
You can't make a monkey write good code. But if you raise your expectations
(within reason), people can often rise to them. Especially if you give them
a motivation ("we're getting attacked!").
> 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.
But the solution is not to just ignore the problem.
Offer the developers some clues.
Eventually, the clueful ones will outnumber the clueless ones, and the
clueless ones find that it's hard to compete. Imagine a world where
_most_ developers knew the basics, and insert a clueless one.
Now the clueless one better learn, or their peers are likely to
have them removed.
--- David A. Wheeler
dwheelerat_private
This archive was generated by hypermail 2b30 : Mon Jan 20 2003 - 16:03:30 PST