Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> Linda Walsh <law@sgi.com>
> > yoann@mandrakesoft.com wrote:
> > > Linda Walsh <law@sgi.com> writes:
>
> [...]
>
> > > > buffer-stack overruns are one of the most common exploits.
> > > > It seems making that more difficult to exploit would help. But a single
> > > > brick does not build a wall. It's part of a wall.
>
> > > A specialized library preloaded before the soft to monitor is much more
> > > serious in this case, this library cauch call to dangerous function and
> > > control the size of the destination buffer ( by walking throught the
> > > stack) if the size which will be written is > than the dest buffer
> > > size, the program is killed.
>
> > Add that as well.
>
> strncpy(3) and its ilk instead of strcpy(3) et al is standard
> recomendation, take a look at the Secure-Programs-HOWTO for instance.
Sorry, but i think the vast majority of people
*here* know how to write secure programs.
The problem is existing programs using non secured functions.
> (BTW, how would this mythical function(s) know the buffer bounds just by
> looking at the stack?)
This isn't *this* mythical function.
as i've already said, you LD_PRELOAD a library which provide a replacement
for dangerous function like strcpy...
The address of the original strcpy() function (in libc) is overwriten,
at load time, by the address of this replacement function ( provided
by the preloaded library )...
Then when your program calls for exemple strcpy(), he isn't using the libc strcpy()
but the strcpy() provided in your preloaded library.
Now in the preloaded library, you're free to do what you want,
and in this case, what we want is bound checking.
> Real problem is that there are people doing string
> copies by hand, or screw up the bound computation...
Yes, but the *vast* majority of the problem is fixed by this kind
of library.
Ps : i can't post the URL of the library i'm talking about...
i'm not allowed to until the press release is done.
And yes, it's LGPL'ed software :-)
--
-- Yoann, http://prelude.sourceforge.net
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST