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 [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
