[15940] in bugtraq

home help back first fref pref prev next nref lref last post

Re: StackGuard with ... Re: [Paper] Format bugs.

daemon@ATHENA.MIT.EDU (Morten Welinder)
Mon Jul 24 21:11:25 2000

Message-Id:  <200007241748.TAA15154@tyr.diku.dk>
Date:         Mon, 24 Jul 2000 19:48:34 +0200
Reply-To: Morten Welinder <terra@DIKU.DK>
From: Morten Welinder <terra@DIKU.DK>
To: BUGTRAQ@SECURITYFOCUS.COM

mixter@2xs.co.il wrote:

> It is a bad idea to have any format functions accept format
> strings that aren't hard coded at compile time. All these
> functions need to have one format argument at one location,
> which definitely needs to be a hard-coded string, (using and
> enforcing const). Per definition, it is arguably possible to
> supply variable format strings in a program, but it is
> rarely practically used, and it shouldn't be practically
> used. At least, when supplying any format function a
> non-constant format argument, the compiler should spit out a
> big warning, and it should do that by default without
> warnings enabled.

As a guesstimate, three out of four format strings in newer GNU
programs are non-constant.  That hardly qualifies as rare.  I think
you forgot about internationalisation.

Here's a sample from Gnumeric:

    s = g_strdup_printf (
          _("Workbook %s has unsaved changes, save them?"),
	  g_basename (wb->filename));


(Which reminds me: I sure hope that the language files cannot be
controlled by a malicious user.  That would allow putting extra
%-escapes into just about any format string.  Ugh.)


Morten

home help back first fref pref prev next nref lref last post