Re: Stack growth direction to thwart buffer overflow attacks
From: Nick Maclaren (nmm1_at_cus.cam.ac.uk)
Date: 08/15/03
- Next message: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Previous message: Matt Curtin: "Re: Certification & Accredition????"
- In reply to: Barry Margolin: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Tony Nelson: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Tony Nelson: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Frank Cusack: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 15 Aug 2003 17:47:48 GMT
In article <Sx7%a.124$mD.56@news.level3.com>,
Barry Margolin <barry.margolin@level3.com> wrote:
>In article <bhi3mc$rgd$1@pegasus.csx.cam.ac.uk>,
>Nick Maclaren <nmm1@cus.cam.ac.uk> 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);
by:
strncpy(target,source,target_length);
If you are writing decent code, you are replacing:
if (strlen(source) > target_length-1) fail("overflow");
strcpy(target,source);
by:
target[target_length-1] = '\0';
strncpy(target,source,target_length);
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.
Regards,
Nick Maclaren.
- Next message: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Previous message: Matt Curtin: "Re: Certification & Accredition????"
- In reply to: Barry Margolin: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Tony Nelson: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Tony Nelson: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Frank Cusack: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|