Re: Secure C programming
- From: Kelsey Bjarnason <kbjarnason@xxxxxxxxx>
- Date: Wed, 2 Jan 2008 02:25:55 -0800
[snips]
On Mon, 31 Dec 2007 11:46:14 -0800, Golden California Girls wrote:
Think your finger is pointing in the wrong direction. Anyone who knows humans
knows that an IQ of 100 is average. A person who designs something that they
know will be used by an average person but doesn't design it for use by such a
person is the one who should have the fault heaped on them. When the standard
library and strings were defined, security may not have been an issue. Bad
future prediction I will forgive. However I can't forgive the standards people
for continuing to permit it. Depreciated should be enforced. Yes, break the
program or make them compile it under the old standard.
This doesn't seem to make a lot of sense to me, as it seems to be looking
in the wrong direction entirely.
Joe Sixpack doesn't need to have a bulletproof set of string functions in
the standard library, he never uses them directly. What he needs is a
bulletproof application.
So take the case of the string functions. strcpy is a good example. The
user enters some data, my code uses strcpy to stuff it into a buffer.
Does the user benefit if the strcpy first examines the string, ensuring
that the resultant buffer is large enough and reallocating if necessary?
Probably not, because I - the programmer - will already have done just
such a thing already. I'll have examined the length of his input and
allocated enough to store it, or processed it piecemeal, reallocating as I
go, etc. If it's simply too damn big, I'll reject it, if there's no
memory left to deal with it, I'll do something else - toss an error, say -
but I don't need the strcpy function to hold my hand for me by doing all
this.
Even worse, there are many cases where the strings I process will be known
to be smaller than the size of the buffer, and what I want is not
hand-holding, but efficiency in processing them. Having them spend their
time doing completely pointless tasks such as validating the length is not
what I need from them, I need them to work efficiently.
Thus there are at least two distinct "levels" of code: code exposed to
unknown, unpredictable data, and code exposed to known data. One set
benefits from such hand-holding, the other suffers potentially enormous
losses of efficiency from it. Making it _all_ behave as if it were "level
one" code benefits nobody but the clueless coder who doesn't bother to
check such details in the first place.
If you want to create a "level one" library, one that does all this sort
of hand-holding, by all means, do so; such checking is, in fact, necessary
in many parts of a program, we just generally do it ourselves. However,
in doing so, kindly do *not* mess with the "level two" library, where
efficiency is the name of the game: if we want the checking, we'll use it
where it's appropriate, not where what we're trying to do is the actual
"meat" of the job.
Yeah, fine, some coders skip such validation. Good ones have some means
to validate their code before releasing it to production - or to the
world. Bad ones, well, a bad programmer is somewhat less likely to do
this, but then, is this sort of thing really going to make his code good?
Or is it simply going to give him a sense of false security: "nothing can
go wrong, because these functions protect me"?
.
- Follow-Ups:
- Re: Secure C programming
- From: Golden California Girls
- Re: Secure C programming
- From: Chris Hills
- Re: Secure C programming
- Prev by Date: Re: Definition of expression and statement.
- Next by Date: Re: Table based programming.
- Previous by thread: Re: Secure C programming
- Next by thread: Re: Secure C programming
- Index(es):
Relevant Pages
|
