Re^4: use of print f and sprint f

[ikegami]

yes, perl is vulnerable. (There's a "but" explained below.) We can see it that it's vulnerable here:

$f = "%%%%";
printf("$f\n");

If perl wasn't vulnerable, it would display %%%% instead of %%. However, the vulnerability cannot be exploited. Perl's version of the (s)printf functions will not clobber the stack if the numbre or replaceables does not match the number of the arguments. What you'll get is incorrectly formatted data (which could possibly be used to exploit something else), but that's it.

[blokhead]

cannot be exploited

Depends on what you mean, I guess.. Check out the perldoc, and look at the %n format. You can set values.

   %n   special: *stores* the number of characters output so far
        into the next variable in the parameter list

Suppose I have the following code:

my $name   = ...; ## from user input
my $amount = ...;

printf "$name : \$%.02f\n", $amount;

# instead of
# printf "%s : \$%.02f\n", $name, $amount;

Now, if a clever hacker goes in and inputs

$name = (" " x 5000) . "%n";

then after the code runs, $amount will be set to 5000. This is a pretty rare set of circumstances, but still something to watch out for.

Update: see also Re: $#="%c"; possible bug

[!1]

I'm sorry, but I don't understand what your point could possibly be. The documentation states that the first parameter to printf is expected to be a string with placeholders that begin with % and that you should use %% when you want an explicit %. Your assertion that it should print %%%% does not follow from anything in the documentation. Perhaps I'm missing something so could you please explain yourself a little better?

[ikegami]

We were talking about using:
printf("$l, $j, %.3f ...\n", $Hx, ...);
rather than
printf("%s, %s, %.3f ...\n", $l, $j, $Hx, ...);
and the question was whether the first one was unsafe.

My snippet demonstrated that escapes inside $l do get processed by printf (which to me is obvious) and therefore printf is subject to coersion by the user ("vulnerable") if the first method is used. It's not as vulnerable as C version, but it's still dangerous.