Re: Stack growth direction to thwart buffer overflow attacks

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

Date: Wed, 20 Aug 2003 08:10:12 +0000 (UTC)

phn@icke-reklam.ipsec.nu writes:

]In comp.security.unix Frank Cusack <fcusack@fcusack.com> wrote:
]> On Tue, 19 Aug 2003 09:27:43 -0700 Frank Cusack <fcusack@fcusack.com> wrote:
]>> On Tue, 19 Aug 2003 15:42:34 +0000 (UTC) phn@icke-reklam.ipsec.nu wrote:
]>>> Well, selecting your vendor is an art. Noone forces yoo to use
]>>> obsolete vendors faulty implementations.
]>>
]>> That's not the right attitude if you care about thwarting buffer overflow
]>> attacks. (Isn't that how this thread started?) You have to write code
]>> defensively. People WILL use your code where you don't expect it.

]> Also, both Solaris and GNU/glibc have faulty implementations of strncat().
]> They are not obsolete vendors.

]Most vendors has bugs. Knowing them and accepting fixes is part of life.
]Vendors that does not fix broken things might find themself obsolete
]in some future. At lest if they don't reside i seattle :-)

??? The whole purpose of this thread was to ask whether there were
programming standards which could help to alleviate stack overflow bugs.
And your response is " Most vendors has bugs. Knowing them and accepting
fixes is a part of life" Once upon a time that was the attitude to
airplanes. It 10 or 20 major airliners fell out of the air every year,
well one had to accept bugs. It was learning to use best engineering
practice which led to much much safer planes (that plus tort law which
ensured that economics would also play in the direction of safer
airplanes). The question here was whether enforcing the use of the strn
functions would be a step in that direction. It seems to be a very
uncertain step.