This is not a buffer overflow.
You're causing a SEGV by attempting to address a non-existant argument
to printf. You don't need a large number to do this--the same happens
with:
perl -e 'printf q/%1$vs/'
Addressing memory (or the failure to do so) is not a security risk in
the same way that a buffer overflow is: the program simply aborts as
opposed to continuing to run, potentially executing exploit code.
It may be worth considering bounds-checking the index to svargs, if only
to produce a more meaningful error than "Segmentation fault".
--bod
> >I haven't had time yet but I imagine it might be possible to gain root
> >through perl-suid.
> This is not a buffer overflow.
> You're causing a SEGV by attempting to address a non-existant argument
> to printf. You don't need a large number to do this--the same happens
> with:
> perl -e 'printf q/%1$vs/'
> Addressing memory (or the failure to do so) is not a security risk in
> the same way that a buffer overflow is: the program simply aborts as
> opposed to continuing to run, potentially executing exploit code.
Although this is not a buffer overflow, there have been a number of
printf-based exploits for C programs that do their work by tricking the
program into reading from "uninitialized" locations in memory. The fact
that this is not a buffer overflow is not itself evidence that it cannot be
exploited; if this is indeed a segfault, a segfault when trying to read from
one memory address can easily become an exploit when reading from another.
Still, as noted in the bug history, allowing untrusted printf strings from
the user or using horribly broken printf format strings is more a bug in the
perl *program*, not in the perl *interpreter*...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
> You're causing a SEGV by attempting to address a non-existant argument
> to printf. You don't need a large number to do this--the same happens
> with:
>
> perl -e 'printf q/%1$vs/'
This was because "%vs" by itself did strange things. Same with "%vc",
"%vn", and even "%v%"'. Fixed by change 26321.
--Gisle