Bugtraq mailing list archives
[linux-security] Re: so-called snprintf() in db-1.85.4
From: aleph1 () DFW NET (Aleph One)
Date: Thu, 10 Jul 1997 07:31:27 -0500
---------- Forwarded message ---------- Date: Wed, 9 Jul 1997 11:13:31 +0100 From: Glynn Clements <glynn () sensei co uk> To: linux-security () redhat 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 <glynn () sensei co uk>
Current thread:
- [linux-security] Re: so-called snprintf() in db-1.85.4 Aleph One (Jul 10)