[linux-security] Re: so-called snprintf() in db-1.85.4

aleph1DFW.NET

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Aleph One: "[linux-security] Re: Re: so-called snprintf() in db-1.85.4"
• Previous message: Aleph One: "A New Fragmentation Attack"

---------- Forwarded message ----------
Date: Wed, 9 Jul 1997 11:13:31 +0100
From: Glynn Clements <glynnsensei.co.uk>
To: linux-securityredhat.com
Subject: [linux-security] Re: so-called snprintf() in db-1.85.4


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 <glynnsensei.co.uk>

• Next message: Aleph One: "[linux-security] Re: Re: so-called snprintf() in db-1.85.4"
• Previous message: Aleph One: "A New Fragmentation Attack"