Re: Stack growth direction to thwart buffer overflow attacks
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: Fri, 15 Aug 2003 22:53:28 +0000 (UTC)
"Rupert Pigott" <email@example.com> writes:
]"Barry Margolin" <firstname.lastname@example.org> wrote in message
]> In article <email@example.com>,
]> Rupert Pigott <firstname.lastname@example.org> wrote:
]> >"Barry Margolin" <email@example.com> wrote in message
]> >> In article <firstname.lastname@example.org>,
]> >> Nick Maclaren <email@example.com> 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
]> >> than just adding one parameter to a function call?
]> >I don't want to jump in and speak for Nick here. From my OWN point
]> >of view adding a parameter is just Yet-Another-Thing-To-Get-Wrong.
]> But the choice is between "doing something and possibly getting it wrong"
]> and "doing nothing which is almost always wrong". Right now we've got
]> of the latter.
]I'm not sure you really get it... That extra parameter is just
]another thing for the guy using the library to get wrong. If
]that's wrong your safeguard blown away. The fundamental problem
No. It can still be a safeguard even if he gets it wrong. We are trying
to prevent attacks, not bugs. Of course if we could eliminate all bugs,
we would not have to worry. But, given that programmers write buggy
code, how can we prevent those bugs from being useable in launching and
external attack. (and I do not include DoS attacks here-- ie an attack
which excites the bug and causes a crash of the program-- that is
obvious. It is the secret attacks where the opposition obtains root
silently that are the problem.)
]is getting the bugger to *THINK* about what the limits should
]be in the first place, until that happens providing mechanisms
]for enforcing the limits is pretty irrelevant. :)