Re: SECURITY: bug in Berkeley DB on some systems (eg. Solaris <= 2.5) [#375]
- From: Sleepycat Software <db abyssinian sleepycat com>
- To: gnome-list gnome org
- Cc: devernay istar fr
- Subject: Re: SECURITY: bug in Berkeley DB on some systems (eg. Solaris <= 2.5) [#375]
- Date: Fri, 11 Dec 1998 10:11:41 -0500 (EST)
Hi, Frederic, Keith Bostic from Sleepycat Software here. Amy Adams asked
me to review your email.
> From: Frederic Devernay <devernay@istar.fr>
>
> I propose that you modify db to either:
> a- make the fake snprintf and derivatives static wherever they're used
This is going to be a pain, I really don't want to do this, although we
probably could.
> b- not use snprintf if it's not in the system libraries
This isn't really an option, as it would limit the number of places where
Berkeley DB can run.
> c- provide a _clean_ implementation of snprintf (there are quite a lot
> around here, in various implementations of libc, and in glib -- which
> comes with gtk)
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.)
> 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?
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
Sleepycat Software Inc. db@sleepycat.com
394 E. Riding Dr. +1-978-287-4781
Carlisle, MA 01741 http://www.sleepycat.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]