Re: Stack growth direction to thwart buffer overflow attacks

From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 08/16/03


Date: Fri, 15 Aug 2003 22:53:28 +0000 (UTC)


"Rupert Pigott" <roo@dark-try-removing-this-boong.demon.co.uk> writes:

]"Barry Margolin" <barry.margolin@level3.com> wrote in message
]news:XY9%a.130$mD.124@news.level3.com...
]> In article <1060970338.228041@saucer.planet.gong>,
]> Rupert Pigott <roo@dark-try-removing-this-boong.demon.co.uk> wrote:
]> >"Barry Margolin" <barry.margolin@level3.com> wrote in message
]> >news:Sx7%a.124$mD.56@news.level3.com...
]> >> 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?
]> >
]> >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
]lots
]> 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

Yes.

]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. :)



Relevant Pages

  • Re: Anomaly Based Network IDS
    ... is NOT used to detect attacks. ... > one single zero day attack. ... > time looking at past security bugs knows they could be anything. ...
    (Focus-IDS)
  • Re: Anomaly Based Network IDS
    ... > Crying wolf: False alarms hide attacks ... > one single zero day attack. ... > security vulnerability not yet shown to the public. ... > time looking at past security bugs knows they could be anything. ...
    (Focus-IDS)
  • Re: [Full-disclosure] ICQ 6 protocol bug?
    ... At which point you're probably trading known bugs for unknown bugs. ... Pidgin - at which point you're trading known ICQ bugs for unknown Pidgin bugs. ... What client am I most likely to see actual attacks against? ...
    (Full-Disclosure)
  • RE: bill gates claim about security vulnerabilities per LOC inUnix versus Windows
    ... While attacks on Windows systems running Microsoft's IIS Web server ... > continues this trend with a whopping 485 bugs attributed to Linux and a more ... community see's these problems as bugs and tries to fix them. ... It takes time to learn to tell the difference between good methodology ...
    (SecProg)
  • Re: Stack growth direction to thwart buffer overflow attacks
    ... The fundamental problem ... to prevent attacks, not bugs. ... Of course if we could eliminate all bugs, ... ]for enforcing the limits is pretty irrelevant. ...
    (comp.security.unix)