Re: SECURITY: bug in Berkeley DB on some systems (eg. Solaris <=2.5) [#375]

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Fri, 11 Dec 1998, Sleepycat Software wrote:

> I'm certainly happy to consider this, but I've never seen a version of
> any printf-style function that I'd want to add to our distribution and
> maintain.  The "safe" versions that I've seen generally consisted of
> signal handlers and/or malloc calls wrapped around an "unsafe" version,
> neither of which is possible in our environment.  First, we're a library,
> so we can't touch the signal handlers.  Second, our most common error
> message is ENOMEM, so doing further malloc's isn't a good plan.
> 
> Regardless, if you know of a simple one that we can support/maintain
> reasonably, I would be interested in adding it to our distribution.
> (Sorry to have to ask you to send me the code, but I poked around the
> GNOME distribution and it wasn't obvious where to find it -- all I could
> find was gnome-libs-0.30.1/support, and that looked pretty complex, i.e.,
> signal handlers, mallocs and so on.)

I don't know the condition of the code but it is in glib, and should be
available from ftp://ftp.gtk.org/pub/gtk/v1.1/glib-1.1.7.tar.gz
 
> > This bug should be considered serious. Not just because I spent a few
> > hours trying to find why a libc function gives the wrong result, but
> > because good software usually RELIES on the security offered by
> > snprintf.
> 
> I'm not quite convinced.  When you found this failure, what failure
> mode were you seeing?  Have you actually managed to overflow a buffer
> in Berkeley DB?

The problem isn't really in berkeley DB per se, it's that the program
linking with berkeley db gets a broken snprintf because berkeley DB comes
first on the link line(At least as I understand the problem).  If berkeley
DB is going to have a local snprintf implementation, it should be static
anyway, since I don't think it is the intenet of Berkeley DB to export a
snprintf to everyone else. Unfortunately this can be a real pain, so maybe
berkeley DB could use another snprintf with a different name that calls
the system one if it exists, and an internal one if it doesn't(This being
determined at compile time).  Hmm, I wonder if there is a way to make a
library that only exports certain symbols, like winblows DLL's do, other
than using static.

The reason why compile time detection fails is that a user may have
compiled berkely DB under Solaris 2.5 and just use the binaries under 2.6.  
This is why you can have problems with compile time detection.  PERL could
be broken if it uses snprintf and gets the broken one from berkeley DB
even if it is compiled on a system with a working snprintf.  This, IMHO,
is bad news.

Manish Vachharajani               Some Haiku: A crash reduces
<mvachhar@vger.rutgers.edu>                   your expensive computer
                                              to a simple stone - Unknown