[lug] Security notice and Ramen

[D. Stimits]

Bell labs wrote an article about buffer overflow attacks, and produced
some alternate functions to replace glibc ones, but they are not
installed by default, at least not that I know of. When individual weak
points are exploited, it isn't at all unusual for a fix to be
incorporated at the next version, but it would probably be nearly
impossible to find and alter all of them as preventive work. Check out
libsafe:
http://www.bell-labs.com/org/11356/libsafe.html
http://www.bell-labs.com/org/11356/docs/usenix00/paper.html

Keith Herold wrote:
> 
> I thought that the gnu string libraries had some overflow safe variants, allowing
> only n characters where n is the size of the buffer, and automatically append a
> \0.  Don't remember the names, although CERT or one of the bugtraq pages ought to
> detail them.
> 
> --Keith
> 
> "D. Stimits" wrote:
> 
> > "Scott A. Herod" wrote:
> > >
> > > Not Ramen itself but I have had to deal with an attack from the
> > > same root kit.  ( New rule, if you put up a machine outside
> > > the firewall, and don't follow the network rules, some friends with
> > > tin snips will come visit you and emacs is going to be hard for you to
> > > use again. )
> > >
> > > I'm only familiar with the 6.2 exploit and there, as the advisory
> > > probably mentioned, a patched version of statd have been available
> > > at least since Nov.
> > >
> > > As for other holes, I'm sure new ones will be found.  For example,
> > > how old is the lpd attack used against RH 7.0?  ( Of course, I've
> > > not written enough C/C++ networking code to understand why it's so
> > > hard to close buffer overflow attacks. )
> >
> > A big part of making buffer overflow popular is because of functions
> > that expect a NULL-terminated string (i.e., sprintf/sscanf and friends
> > are easy to find and work on; using snprintf avoids much of that iff the
> > length of the string measured is itself safe, not depending on NULL).
> > Those functions are usually part of glibc, and well-known how to work on
> > them to break them.
> >
> > A nice way to avoid making your C/C++ app a target is to not use
> > NULL-terminated char string C/C++ functions (for example, use a
> > std::string instead of char*), without a predefined means of limiting
> > how far it is going to allow that string length limit. How many
> > applications out there might use a char* style string? HUGE list.
> >
> > >
> > > Scott
> > >
> > > John Starkey wrote:
> > > >
> > > > Has anyone had to deal with the ramen toolkit? I was just made aware that
> > > > some machines on the same network as mine have been compromised. I'm not
> > > > running any of the specified services and it looks like i'm clear but CERT
> > > > just issued the Incident Note last week. So i'm wondering if there are any
> > > > other holes that could be used?
> > > >
> > > > Funny, their using /usr/src/.poop as the root dir. Such jokers :}
> > > >
> > > > TIA,
> > > >
> > > > John
> > >
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug