Re: Stack growth direction to thwart buffer overflow attacks
From: Nick Maclaren (nmm1_at_cus.cam.ac.uk)
Date: 15 Aug 2003 17:47:48 GMT
In article <Sx7%a.124$mD.email@example.com>,
Barry Margolin <firstname.lastname@example.org> wrote:
>In article <email@example.com>,
>Nick Maclaren <firstname.lastname@example.org> wrote:
>>Firstly, in the case of functions like strcpy, it is NOT much easier
>>to provide the correct length than to do your own checking.
>Could you explain this? How could writing your own checking code be easier
>than just adding one parameter to a function call?
Eh? Inserting one line that needs no further information than the
strncpy call you are proposing is a trivial task, even for a third
class BASIC-only programmer. Even if you are writing such shoddy
code that you don't check that you are leaving an unterminated
string to cause problems later, you are only replacing:
if (strlen(source) < target_length) strcpy(target,source);
If you are writing decent code, you are replacing:
if (strlen(source) > target_length-1) fail("overflow");
target[target_length-1] = '\0';
if (target[target_length-1] != '\0') fail("overflow");
NOT a big improvement!
>>One of the common causes of problems is that a 'solution' eliminates
>>enough of the easy cases so that lazy programmers stop even trying
>>to do tackle the problem themselves. In turn, this means that the
>>number of nasty cases increases. As it is common for 90% of the
>>bugs to be easy, but 90% of the problems to be caused by hard bugs,
>>this often REDUCES the overall reliability.
>We're talking about programmers who aren't even getting the easy cases
>right. If the cost of preventing 100 easy cases is 10 more nasty cases,
>that seems like a net win.
Think about it. If the cost of a hard case getting past initial coding
is 100 times that of an easy case doing so (which is not unusual), it
is a pretty catastrophic loss.