Re: Stack growth direction to thwart buffer overflow attacks
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 08/16/03
- Next message: Bill Unruh: "Re: Stack growth direction to thwart buffer overflow attacks"
- Previous message: Barry Margolin: "Re: Stack growth direction to thwart buffer overflow attacks"
- In reply to: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 15 Aug 2003 22:50:03 +0000 (UTC)
"Rupert Pigott" <roo@dark-try-removing-this-boong.demon.co.uk> writes:
]"Bill Unruh" <unruh@string.physics.ubc.ca> wrote in message
]news:bhjb2c$rjj$1@string.physics.ubc.ca...
]> "Rupert Pigott" <roo@dark-try-removing-this-boong.demon.co.uk> writes:
]>
]> ]"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.
]>
]> ]In addition to be Yet-Another-Thing-To-Get-Wrong it does not really
]> ]tackle the root cause of a lot of these errors. In my experience
]> ]the most common root cause is a failure to adequately design and
]> ]implement code that accepts input from the outside world.
]>
]> But it tends to transfer the bug from one that is externally useable, to
]> and internal bug which can affect the operation of the program, but is
]> much harder to exploit from outside.
]Err, if the parameter allows the input to run off the end of
]the buffer, then what ? Like "Oh, I thought I was always given
]a 256 char buffer...".
That may well cause a crash, but will be hard put to be useable in a
buffer overflow attack-- it is hard to both find the appropriate return
pointer and insert sufficient code to launch that attack in the
difference between 256 and the actual buffer length.
Not all buffer overwriting can be used for a buffer overflow attack.
Of course the code may still evince bugs, and may crash, but there are
lots of ways of accomplishing that with bad programming.
- Next message: Bill Unruh: "Re: Stack growth direction to thwart buffer overflow attacks"
- Previous message: Barry Margolin: "Re: Stack growth direction to thwart buffer overflow attacks"
- In reply to: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Rupert Pigott: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
