From coley@linus.mitre.org

Hello all,

I apologize if my vague email yesterday has caused any problems. I
wanted to be certain that I was passing the report to the proper
people.

In short, Perl programs can be subjected to certain types of format
string vulnerabilities [1], similar to C programs, through the sprintf
and printf functions. One might regard this as an implementation
error and not a bug in Perl (i.e. programmers don't always use
sprintf/printf correctly in Perl code, just like they don't use them
correctly in C).

However:

1) I don't know the Perl "guts" in how it handles format strings, so
I'm not sure whether they can be manipulated to cause buffer
overflows within Perl itself.

2) The Perl taint checker does not flag certain insecure calls early
enough to prevent some types of format string attacks. I
understand that Perl developers may decide not to modify the taint
checker to be more paranoid, but I wanted to bring up the issue
before publishing the general risk of format strings in Perl
programs.

A more detailed writeup is below. It's a rough draft, so I apologize
for that. Corrections, clarifications, and Perl developer actions (if
any) are appreciated. Again, I understand that Perl developers may
wish to leave the taint checker alone.

Thanks and regards,
Steve

[1] http://online.securityfocus.com/guest/3342

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Format string vulnerabilities in Perl programs
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

Author: Steve Christey
Date: September 30, 2002

Other Credits: Jean-loup Gailly (jloup@gailly.net) independently
discovered and reported a Perl format string problem
on September 26, 2002 [1]

SYNOPSIS

Perl programs that provide user-controlled format strings to sprintf()
and printf() may be subject to certain types of format string
vulnerabilities. While the execution of arbitrary code does not
appear to be feasible in the general case (as it can be with C),
attackers may cause other behaviors that have security implications.

Many of these behaviors have analogs in C, but since they do not
result in code execution, the implications are typically ignored in
vulnerability research.

It has been observed that C programmers may use "C style" constructs
when they are new to programming in Perl. Such programmers may be
more likely to use printf and sprintf, since they also appear in C.

Perl's taint checker catches the worst of these problems, but not all
of them. The behavior differs in Perl 5.004 and 5.6.1 (5.6.1 can
identify additional dangerous inputs).

DETAILS

Following are some of the more dangerous/interesting specifiers, along
with their implications.

1) Using the "%n" specifier, the attacker can modify the values of
certain variables that are provided as arguments to print/sprintf,
possibly altering program behavior in ways that have security
implications.

The implications of this problem depend on how the program uses the
variables.

Consider the following pseudo-code:

$input = GetInputFromUser();
if (UserHasAuthenticated($user))
{
$a = 0;
}
else
{
$a = 1;
}
$str = sprintf($input, $a);
if ($a)
{
PromptUserToAuthenticate($user);
}
else
{
DoThingThatOnlyUsersShouldDo($user);
}

If $input is "%10s", then str is formatted with up to 10 spaces
of padding and $a is not modified; but if $input is "%n", then $a
is changed to 0, and the attacker effectively bypasses the check
for authentication.

2) The "%s" specifier, and others that allow field widths to be
defined, can be used to consume a large amount of CPU, memory,
and/or disk, e.g. "%99999s". (Warning: "%999999999s" causes an
unpleasant experience on most systems.)

3) [** this needs exploration **] The "%p" and "%n" specifiers may, in
certain situations, be able to "leak" the values of certain
variables that was not intended by the programmer. This is because
'%p' and "%n" consume variables that are provided as arguments to
the *printf, shifting how they are formatted.

4) Argument shifting via %p (or %n)

[need to come up with a better term, since shift() has meaning in Perl]

Any format specifier can alter the intended format of structured
output. This in turn could corrupt files or enable the
exploitation of vulnerabilities in other applications that process
such output. For example, the '%p' specifier, which prints out a
pointer value, could be used to generate integer values that exceed
the expected range of inputs.

Example:

$index = GetUserInput();
if (($index > 32) || ($index < 0))
{
print STDERR "Error: Index must be between 0 and 32.";
}
($sec,$min,$hour,$mday,$mon,$year) = gmtime(time);
printf DATABASE, "$index %4d/%02d/%02d %02d:%02d:%02d\n",
$year+1900, $mon+1, $mday;

If $index is "1", then the result might be:

1 2002/10/01 06:58:42

But if $index is "%p", the error condition is not detected (since
the string evaluates to 0), and the result would be:

130690 10/01/06 58:42:00

Here, not only does the 'index' value exceed the maximum of 32, but
all the other values are wrong! This is because %p "consumes" the
$year+1900 expression, returning a pointer to the result. All the
other arguments are then "shifted" over, and applied to the wrong
format specifier. Thus the month value is formatted as the year,
the seconds value is formatted as the minute, etc.

5) Cleansing operations that remove spaces could be tricked by using
"%2s" or other format specifiers that generate spaces. Programs
may try to remove spaces when passing arguments to commands, or
formatting data.

Here's one example:

opendir(DIR, ".");
while ($file = readdir(DIR))
{
if ($file =~ /\s/)
{
print STDERR "Warning: '$file' has spaces, replacing with _\n";
$file =~ s/\s/_/g;
}
if ($file =~ /^-(fiprR)+$/)
{
print STDERR "Warning: '$file' matches switches for /bin/cp!\n";
# skip this one.
next;
}
$backup = sprintf("$file.bak"); # C programmers might do this
system("/bin/cp $file $backup"); # but this *is* just an example
}
closedir(DIR);

If $file is set to "-R%2ssubdir", then the check for "dangerous
switches" would fail, and the resulting system call would be:

system("/bin/cp -R subdir subdir.bak");

[*** note: a more feasible example could probably be created. ***]

6) Is there a way to create a format string that handles a ../ ??
Maybe not directly, but perhaps "argument shifting" can accomplish
this?

Other Attack Scenarios

Some feasible attack scenarios involve Perl programs that generate log
messages or reports:

- filenames containing format specifiers could alter which files are
processed

- IP addresses whose DNS reverse lookup includes format strings
could be returned as the result of gethostbyname() [does the
taint checker spot these?]

Some discussion on format strings and the taint checker

In 5.004:

The taint checker apparently does not flag filenames as tainted
(e.g. as obtained from the readdir() function). Presumably, other
types of "indirect input" may not be tainted. However, it does
properly spot "traditional" sources of input such as stdin and
environment variables.

In 5.6.1:

Filenames are properly tainted, and the taint checker properly
terminates the program. While the program is safe from
exploitation through dangerous calls, there is still a denial of
service, which could be a problem with critical code that is
expected to fully complete its task, such as a log processing
program (although the programmer should take the possibility of
failure into account while running in taint mode anyway!)

Note that the taint checker does not exit until a *printf-tainted
variable is passed to a dangerous call such as system(). So, if
the program is not tested with specifiers such as '%n' (which
modifies an argument to *printf), then the taint check may not be
discovered.

Attacks such as resource consumption and data format modification
will still work; however, changing the taint checker to exit as
soon as the printf/sprintf is encountered could break existing
programs.

This is a factor though: "testing" sprintf/printf with normal file
names won't directly trigger the taint checker, unless %n is actually
included in the filename; so, if the programmer tests the Perl code,
but does not include the '%n' option, they won't necessarily find the
taint error. However, a later input with '%n' could cause the program
to halt unecpectedly due to the taint error.

See taintcheck.pl for what I tried.

Note: the taint checker doesn't complain when system() is called with
arguments in the following fashion:

system("/bin/echo", $tainted_var1, $tainted_var2);

The following example properly generates an error from the taint
checker, using input from stdin:

$a = <STDIN>;
chomp($a);
$str = sprintf("$a.txt");
system("/bin/echo $str");

The following example also generates an error from the taint checker,
using input from a directory listing:

opendir(DIR, ".");
while ($file = readdir(DIR))
{
system("/bin/echo $file");
}
closedir(DIR);

SAMPLE VULNERABLE PROGRAMS

An apparently old version of ftplogcheck, used for processing wu-ftpd
logs, contains a line:

printf REPORT "$time $host $filesize $filename $name\n";

Result: attackers can hide file activities by using format specifiers
in incoming filenames that will alter the actual filename that was
accessed.

perl-nocem - a script that was apparently considered for inclusion in
INN 2.0 beta, but not distributed with INN 2.3.3.

http://www.isc.org/ml-archives/inn-workers/2001/05/msg00177.html

The "logmsg" appears to be subject to format string issues when
"use_syslog" is not active; the NNTP message ID ($msgid) looks like it
could be modified with format strings such as %p, possibly resulting
in processing incorrect articles.

http://www.lns.cornell.edu/~pvhp/perl/mac/scripts/SizeByCreator

- seems like a user-only script

Needs investigation:

http://search.cpan.org/src/JHI/perl-5.8.0/ext/Sys/Syslog/Syslog.pm

- the syslog() function uses sprintf() on a "mask" variable;
unknown if format strings can be passed into it.

RESOLUTION

When writing Perl programs, follow these guidelines.

1) Use constant strings for formatting.

2) Do not use Perl variables in format strings, e.g. "$bad %10s"

3) Run your program with taint checking enabled, which can protect
against many of the problems identified here.

DETECTION

Detection of suspicious code is slightly more difficult than it is for
C code. Constant strings can contain Perl entities such as variables,
which are inserted into the string before it is passed to
printf/sprintf.

$fmt = "%10s";
printf("THIS IS A POTENTIALLY VULNERABLE $fmt FORMAT STRING\n");

************** Sample Vulnerable Programs **************

These programs demonstrate some the problems described above.

#!/bin/env perl

# when run with taint checking (-T), this seems to properly barf about
# dependency errors (try a "clean" format string like "5s%s%s" vs. a
# dirty one with a "%n" in it).

$ENV{"PATH"} = "";

# try as input: "%s%n%s" --> modifies $b

$a = "A";
$b = "B";
$c = "C";
$x = sprintf($ARGV[0], $a, $b, $c);

print "\$a='$a'; \$b='$b'; \$c='$c'\n";

print "$x\n";

system("/bin/echo $a $b $c");

************** End Sample Vulnerable Program **************

********* Sample 2 **********

# Create a directory that contains files with these names:
# %99999s
# %p
# %s
# abc%ndef

# This was gleaned from some real-world code, but the print was
# changed to printf.

# Change what filenames are processed via format strings in
# the filenames, such as a file named "%p%n"
#
# You can "erase" a filename by using '%s', and having this "blank"
# filename could throw off the argument count to system or exec calls,
# which could alter behavior. Consider a backup command like
# exec("/bin/cp", file1, file2) where file1 can be "blanked" out
#
# Similarly, you could "erase" portions of a filename with "%n" or
# "%s". The filename ABC.TXT would be equivalent to ABC%n.%nTXT
#
# You can create very long filenames by using '%999s' (for example).

opendir(DIR, ".");
while ($file = readdir(DIR))
{
printf LOG "PROCESSING FILE $file\n";
# or...
# printf LOG "PROCESSING FILE " . $file . "\n";
}

2) Misuse of format string in log processing, for which many Perl
programs have been written. Could cause larger strings than
expected to be written to files or sent to processes; code that
depends on well-formatted input from the program may be subject to
buffer overflow or other issues.

I've seen several programs that do something like this:

printf "A=$a\n"

******** End Sample 2 ************

********** miscellaneous ***********

- I haven't explored all the issues

Disclosure History

Jun 10, 2002 - Began discovery and investigation of issue; search for
potentially vulnerable programs
Sep 26, 2002 - Jean-loup Gailly (jloup@gailly.net) posts Perl format
string problem in OpenVMS
Sep 28, 2002 - deeper investigation into format specifiers, other
vulnerable programs
Sep 30, 2002 - more writing on security advisory; investigated whether
taint checker did "the right thing"
Sep 30, 2002 - tried to find a way to report a security vuln to Perl
developers (in case taint issue is a Perl bug, and to
consult on possibility of buffer overflows).
Registered to site, only to be told by a web page to
email my report to a certain address. Left out details
in the email because I had no idea who would be viewing
the report at that address.
Sep 30, 2002 - investigated taint checker issues, %p
Sep 30, 2002 - initial response from Perl contact (within 50 minutes)
saying it was OK to post details to that address, gave
an alternate POC just in case.

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
taintcheck.pl
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

#!/bin/env perl

# SMC 10/01/02. Test program for the taint checker.

# Before running this, create a directory and 'touch' the following
# files:
# abc%3sdef
# abc%ndef
# abc%pdef
# abc%sdef

$ENV{"PATH"} = "/bin";

if ($ARGV[0] eq "-stdin")
{
# feed tainted input from stdin through sprintf().
$a = <STDIN>;
chomp($a);
# $a = $ENV{"HOME"};
$str = sprintf("$a.txt");
print "STR='$str'\n";
system("/bin/echo $str");
# system("/bin/echo", $str);
die "No error on -stdin...\n";
}
elsif ($ARGV[0] eq "-dir")
{
# feed tainted input from a directory listing.
opendir(DIR, ".");
$count = 0;
while ($file = readdir(DIR))
{
system("/bin/echo $file");
}
closedir(DIR);
}
elsif ($ARGV[0] eq "-dirs")
{
# feed tainted input from a directory listing through sprintf().
opendir(DIR, ".");
$count = 0;
while ($file = readdir(DIR))
{
$x = sprintf("$file.txt");
system("/bin/echo $x");
}
closedir(DIR);
}
elsif ($ARGV[0] eq "-dirarg")
{
# feed tainted input from a directory listing through an arg
#
# This will not barf with format strings like %s, but it *will*
# barf if it runs across a file with a %n in it.
opendir(DIR, ".");
$count = 10;
while ($file = readdir(DIR))
{
printf "FILE=$file.txt\n", $count, $a, $b, $c;
# $c = sprintf("FILE=$file.txt\n", $count, $a, $b, $c);
print "Fake-command: /bin/echo count=$count a=$a b=$b c=$c\n";
system("/bin/echo count=$count a=$a b=$b c=$c");
}
closedir(DIR);
}
else
{
print "Usage: taintcheck.pl [-stdin|-dir|-dirs|-dirarg]\n";
}

Consultation required on possible Perl security issue #5968

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions