Re: [Bug-tar] Format-string warnings in 1.26

[Eric Blake]

On 07/29/2011 12:30 AM, Paul Eggert wrote:
> On 07/28/11 23:04, Daniel Macks wrote:
> > It's a valid concern when the string being fed comes from a gettext translation
> > (or really anything else that derives from user-controllable data).
>
> The comment in parentheses is valid, but the comment
> about gettext is not.  If gettext is vulnerable to the
> kind of manipulation you're suggesting, then GNU tar
> is vulnerable even with the patches you sent in.
>
> For example, there's no point to changing this line:
>
>    fprintf (stderr, _("Valid arguments are:"));

Coreutils' policy is to use fputs, rather than fprintf with a format 
string of %s.  That is, if you have a string that does not have any %, 
then you are better off printing the string directly rather than wasting 
the time of going through the printf family for a single format string 
of %s.

> while leaving this line alone:
>
>    fprintf (stdlis, _(" link to %s\n"), quotearg (st->link_name));
>
> Any gettext-based attack that would work against the former, would
> also work against the latter, and since we cannot change the latter
> there's little point to cluttering up the code by changing
> the former.

Gettext marks certain strings as being a printf-format content, if you 
pass the right options to xgettext.  Strings marked in that manner are 
checked by gettext to not introduce any insecurities due to a 
translation adding % incompatible with the original string.  Therefore, 
you can safely avoid worrying about gettext introducing a security hole 
for this type of non-constant format string.  Additionally, clang is 
smart enough to honor the same attributes as gcc - if the outer function 
(fprintf) is marked with attribute __format__(__printf__,,), and the 
inner function (_, aka gettext) is marked with attribute __format_arg__, 
then both compilers know that a string literal argument to the inner 
function is just as safe as if you had directly passed the same string 
literal argument to the outer function.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org