Secure Coding mailing list archives
Re: New Microsoft Security Tool for developers
From: der Mouse <mouse () Rodents Montreal QC CA>
Date: Sat, 13 Dec 2003 15:50:16 +0000
Okay, now to this little gem. What's wrong with this code? It's a code sample I saw recently on outlining a safe way to write buffer overrun-free code.
void noOverflow(char *str) { char buffer[10]; strncpy(buffer,str,(sizeof(buffer)-1)); buffer[(sizeof(buffer)-1)]=0; /* Avoiding buffer flow with the above two lines */ }
Nothing, wrt avoiding a buffer overrun - it does that Just Fine. Whether there's anything else wrong with it I couldn't say, as nothing quoted (either on-list or on the webpage) says what its interface contract is. If noOverflow's interface spec indicates that it's the caller's responsibility to check for null pointers, then the concern I've seen raised about "what if str is null?" is not applicable; if a null pointer is an acceptable argument, that's a legitimate bug. As for returning an overflow indication, that again depends on what the interface spec says happens if the argument string is longer than 9 characters. That's something I would like to see taught more: interface contracts, what they promise, and - almost more important - what they don't promise. Unfortunately, far too many (attempts at) interface contacts I've seen leave far too many corner cases unspecified. If this were a real function in real code, its interface spec quite likely would not say anything at all about the "str is a null pointer" case or the "str is longer than 9 chars" case - and those omissions would be a worse bug than any bug the code itself might contain. I suspect that merely giving coders properly detailed interface specs would alone reduce bug rates significantly, though unfortunately I know of no research on the matter. In this connection I commend the VAX Architecture Reference Manual as an example. It is full of statements that certain things produce UNDEFINED or UNPREDICTABLE behaviour, where the uppercase terms have relatively precise and clear definitions. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Current thread:
- Re: New Microsoft Security Tool for developers, (continued)
- Re: New Microsoft Security Tool for developers Avner Peled (Dec 12)
- Re: New Microsoft Security Tool for developers Jeremy Thibeaux (Dec 12)
- Re: New Microsoft Security Tool for developers Steve Litt (Dec 12)
- Re: New Microsoft Security Tool for developers Dana Epp (Dec 12)
- Re: New Microsoft Security Tool for developers Steve Litt (Dec 12)
- Re: New Microsoft Security Tool for developers Jack D. Unrue (Dec 12)
- Re: New Microsoft Security Tool for developers Dana Epp (Dec 13)
- Re: What's wrong with this code? Jared W. Robinson (Dec 12)
- RE: New Microsoft Security Tool for developers David Crocker (Dec 12)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 13)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 13)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 13)
- Re: New Microsoft Security Tool for developers Mark Graff (Dec 13)
- Re: New Microsoft Security Tool for developers der Mouse (Dec 15)
- Re: New Microsoft Security Tool for developers Dana Epp (Dec 15)
- Re: New Microsoft Security Tool for developers Crispin Cowan (Dec 15)