Re: Stack growth direction to thwart buffer overflow attacks

From: Barry Margolin (barry.margolin_at_level3.com)
Date: 08/15/03


Date: Fri, 15 Aug 2003 16:06:10 GMT

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?

>|> Most buffer overflows can essentially be traced to lazy programming.
>|> There's two solutions to lazy programming: get rid of all the lazy
>|> programmers, or make it easier for them to program safely (so they can
>|> remain lazy and achieve better results). In an ideal world the first
>|> solution would be used, but we don't live in that world. We have to make
>|> do with the programmers available, so the second solution should help.
>
>Yes, it should. But will it?
>
>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.

-- 
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


Relevant Pages

  • Re: Help with floating point non-reversibility
    ... too common. ... programmers like you" you mean programmers who kept correcting your rookie ... while sweeping on to the grand fallacy, which here, I think, is the ... use of floating point to model the behavior of discrete individuals. ...
    (comp.programming)
  • Re: OO syntax
    ... You have a few people who are proud of their OO implementations giving good reasons why their particular model should be adopted as a standard. ... I am pointing out that the Lua language doesn't offer objects as a primitive type. ... What Lua does instead is to provide meta-mechanisms and some minor syntactic sugar that allows programmers to create and use objects with whatever kinds of semantics make sense for the programmer and application. ... I am saying that I believe that if the people who advocate the various OO systems for Forth would stop thinking in terms of why their OO system is the best and instead focus on factoring what is common between their systems, the result would be a set of primitives that they could layer their OO system on top of. ...
    (comp.lang.forth)
  • Re: Stack growth direction to thwart buffer overflow attacks
    ... >|> do with the programmers available, so the second solution should help. ... As it is common for 90% of the ... >bugs to be easy, but 90% of the problems to be caused by hard bugs, ... If the cost of preventing 100 easy cases is 10 more nasty cases, ...
    (comp.security.unix)
  • Re: Forth and OO design?
    ... Redefinitions aren't the end of the world in Forth. ... And just as Forth programmers create wordlists to ... common name. ...
    (comp.lang.forth)
  • Re: It Hurts When I Do This
    ... requires a syntax for any other attributes. ... a common pitfall. ... It may be a common pitfall among programmers ... In this single instance, Fortran has it wrong. ...
    (comp.lang.fortran)