[lug] Security notice and Ramen
D. Stimits
stimits at idcomm.com
Wed Jan 24 11:29:19 MST 2001
rm at mamma.varadinet.de wrote:
>
> On Wed, Jan 24, 2001 at 10:47:00AM -0700, D. Stimits wrote:
> > jkraai at murlmail.com wrote:
> > >
> > > On Tue, Jan 23, 2001, at 10:25:05 pm Sean Reifschneider <jafo at tummy.com> wrote:
> > > >
> > > > DJB has an RFC or the like for "net strings". [...]
> > >
> > > http://cr.yp.to/proto/netstrings.txt
> > >
> >
> > I actually converted to something like this for other advantages on
> > another app. They're useful for any network traffic, not just security,
> > and not just text strings.
>
> I'm not convinced that this would solve the problem. There are
> secure replacements for all string handling functions in libc
> that expect explicit size information. It's just that people
> don't use the or compile lagacy applications.
>
> Ralf
>
And that is why libsafe was invented. It replaces the actual string
functions in libc/glibc with versions that not only observe stack
frames, but log attempts to go beyond it. Run lengths are in a way like
"strict prototypes"...they force the app writer to always use the
length. And any time a stated length is over the allowed length, it can
be tossed out. Adding run lengths in greatly adds to the ability to "do
the right thing", even if it doesn't force it. std::basic_string<char>
will itself throw an exception if you do try to run it beyond its
capacity, so appending data as it arrives to such a class will
completely break any stack overflow attempts to it; but if you didn't
limit the size of the string, there might be other gotchas, such as
using up lots of memory. No matter how you look at it, there are just a
few gotchas for coding net apps and removing 90% of the holes. The other
10% probably take a much closer look that can't be solved with some very
simple rules.
More information about the LUG
mailing list