linux security - Jul 1997 - so-called snprintf() in db-1.85.4

Hi,

There is a severe problem with the db-1.85.4 library''s Linux
port that can be found on sunsite.unc.edu under
/pub/Linux/libs/db-1.85.4-src.tar.gz (sp?): This library
contains a "snprintf" function which breaks down to a common
sprintf, ignoring the size parameter.  Obviously, this was
thought to be a terribly bad work-around for C libraries which
don''t contain an snprintf routine of their own.  The
consequences of this bug are obvious: Any program which is
linked with libdb.so.1.85.4 and relies on snprintf(3) to do
it''s bounds checking doesn''t have any bounds checking at all.

Note that recent linux C libraries contain an snprintf(3)
function of their own which does it''s job properly.  Thus, the
fix is to simply remove snprintf.o from libdb.

tlr
--
Thomas Roessler ? 74a353cc0b19 ? dg1ktr ? http://home.pages.de/~roessler/
   1280/593238E1 ? AE 24 38 88 1B 45 E4 C6  03 F5 15 6E 9C CA FD DB

Thomas Roessler wrote:
> Note that recent linux C libraries contain an snprintf(3)
> function of their own which does it''s job properly.  Thus, the
> fix is to simply remove snprintf.o from libdb.
A couple of points:

1. I presume that the same applies to vsnprintf.

2. I''ve done `ar d libdb.so.1.85.4 snprintf.o vsnprintf.o'' for
the
static lib.

[mod: snprintf and vsnprintf are defined in the same object file:
 snprintf.o . `ar d libdb.so.1.85.4 snprintf.o'' is sufficient. --REW]

Can anyone confirm whether this is correct for the dynamic
lib:

objcopy -v -N snprintf -N vsnprintf libdb.so.1.85.4 libdb.so.1.85.4-new
mv libdb.so.1.85.4 libdb.so.1.85.4-old
mv libdb.so.1.85.4-new libdb.so.1.85.4

objdump still lists the symbols, but ls -l shows a reduced file size.

[mod: As far as I''ve been able to verify Glynn is correct.
"nm" shows
that the symbols disappear, except that an undefined reference, (now
resolved from libc) remains. My lib had the same problem, but
different version numbers. -- REW]

--
Glynn Clements <glynn@sensei.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----



roessler@guug.de wrote:
> There is a severe problem with the db-1.85.4 library''s Linux port
I just ran nm on my libdb.a and found:

snprintf.o:
00000000 t gcc2_compiled.
00000000 T snprintf
00000014 T vsnprintf
         U vsprintf

Without looking at the code I''d bet that the vsnprintf function
supplied
in this library similarly turns into a vsprintf.

Hal


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBM8OG50Zrb8SDJ8hxAQE77wP/a10vOmulKy3hOcG9bqwBA64m7OEejqv7
7CiRGcRepHyowVMHvp2P7pITCYohGxpEweljnA4iqHy8WG68No8pK2YOjp7RDLda
WcS+CvImoLX7gBZK3LBQpmWqtrHfwO/I3QaqfietW93mG0PPrysRGhUNi94+MKB5
4SUgslHA42U=AkPG
-----END PGP SIGNATURE-----

ldd /usr/sbin/sendmail
        libgdbm.so.1 => /lib/libgdbm.so.1
        libdb.so.1 => /usr/lib/libdb.so.1
        libc.so.5 => /lib/libc.so.5

Does this mean that the all occurences of snprintf in my sendmail are now
susceptible to overflows?  Or might the order of the links to the
libraries override libdb''s snprintf with the libc version?  I am unsure
about how symbols are loaded from libraries...

[mod: I''d vote "YES", sendmail is vulnerable. Strings on
/usr/sbin/sendmail gives "snprintf", quite close to the string
"libdb.so.2.0.0". The order of the links works as it should when
special libraries (like libdb) can override the default (in libc) -- REW]

Thanks for any info,
-vermont@gate.net

On Wed, 9 Jul 1997, Hal DeVore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
>
> roessler@guug.de wrote:
> > There is a severe problem with the db-1.85.4 library''s Linux
port
>
> I just ran nm on my libdb.a and found:
>
> snprintf.o:
> 00000000 t gcc2_compiled.
> 00000000 T snprintf
> 00000014 T vsnprintf
>          U vsprintf
>
> Without looking at the code I''d bet that the vsnprintf function
supplied
> in this library similarly turns into a vsprintf.
>
> Hal
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a
> Charset: noconv
>
> iQCVAwUBM8OG50Zrb8SDJ8hxAQE77wP/a10vOmulKy3hOcG9bqwBA64m7OEejqv7
> 7CiRGcRepHyowVMHvp2P7pITCYohGxpEweljnA4iqHy8WG68No8pK2YOjp7RDLda
> WcS+CvImoLX7gBZK3LBQpmWqtrHfwO/I3QaqfietW93mG0PPrysRGhUNi94+MKB5
> 4SUgslHA42U> =AkPG
> -----END PGP SIGNATURE-----
>