[lug] Security notice and Ramen

[D. Stimits]

rm at mamma.varadinet.de wrote:
> 
> On Tue, Jan 23, 2001 at 05:03:28PM -0700, D. Stimits wrote:
> > Sean Reifschneider wrote:
> > >
> > > On Tue, Jan 23, 2001 at 03:20:00PM -0700, D. Stimits wrote:
> > > >A big part of making buffer overflow popular is because of functions
> > > >that expect a NULL-terminated string (i.e., sprintf/sscanf and friends
> > >
> > > I'd really love to see some network services written in Python or Perl.
> > > You have to be careful to prevent somone from sending a huge string
> > > without a newline, thus using as much RAM as possible, but it shouldn't
> > > be possible to do any buffer overflow attacks.
> >
> > A similar scenario for some of the C++ STL containers. I could imagine
> > someone trying to buffer overflow a std::string for someone with a 56k
> > modem. They'd be sending one string for all day and night, wondering why
> > it wasn't overflowing yet.
> >
> 
> The way to do it is to use comression and have the receiver decompress
> it (many browsers will do on-the-fly-decompression if given the right
> mimetype):
> % dd if=/dev/zero bs=1024 count=5000 > /tmp/ups.txt
> % ls -l /tmp/ups.txt
>   -rw-rw-r--    1 ralf     users     5120000 Jan 24 18:49 /tmp/ups.txt
> % gzip  /tmp/ups.txt
> % ls -l /tmp/ups.txt.gz
>   -rw-rw-r--    1 ralf     users        5003 Jan 24 18:49 /tmp/ups.txt.gz

The net strings stuff parallels compression in a loose sense. It isn't
unusual for compressed data to contain a run length for the upcoming
data; uncompressed data it is possible to figure out where strings end
(which gets us into security trouble), whereas most compressed data
would be a pain if we didn't specify run length ahead of time.

> 
> ;-)
> 
>  Ralf
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug