Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Mar 2014 22:16:08 -0500 (EST)
Subject: Re: possible CVE requests: perltidy insecure temporary file usage

Hash: SHA1

Use CVE-2014-2277 for the issue in which, on all platforms, the
filename string returned by make_temporary_filename might be used for
an attacker's symlink before that filename is used by the perltidy
code to write lines into a file.

> $^O =~ /win32|dos/i || $^O eq 'VMS' || $^O eq 'MacOs'
> Would this be a separate issue on those platforms

We typically don't assign separate CVE IDs in cases where, for the
same version of the software, the vulnerability details are similar
but non-identical on different operating systems.

> Regarding the use of tmpnam, is it safe/not an issue if you open the 
> resulting filename with O_CREAT and O_EXCL (as perltidy does)?

Possibly it depends on the version of Perl or the operating system's
libraries. Maybe someone else knows the precise details. The post
claims 'because a symlink can point to nowhere, the O_EXCL|O_CREAT
test does not suffice: you might still end up making a "new" file,
even one that you own, that's somewhere else than you think it is.' On
at least some recent Linux platforms, that behavior apparently does
not occur. Specifically, if the first argument to IO::File->new is a
symlink, and the target of the symlink is a nonexistent file like
/home/victim/.forward, and O_EXCL|O_CREAT is used, then
/home/victim/.forward is not created.

This question might be relatively unimportant because O_EXCL|O_CREAT
was only used in the IO::File->new call for choosing a filename.
O_EXCL|O_CREAT wasn't used in IO::File->new call that came immediately
after the make_temporary_filename call. This, for example, doesn't
cover the case of a mode 0777 current working directory.

> 1) perltidy creating a temporary file with default permissions instead of 0600

We're not sure that this should be a vulnerability with a CVE
assignment, even though it is a violation of development standards in
some parts of the community. For example:

says "Potential Mitigations ... Temporary files should be writable and
readable only by the process which own the file."

(Obviously, "own" is a typo of "owns" there. MITRE will probably fix
that later.)

It looks like the most common use case is for perltidy to read a .pl
file in the current working directory, and then create a
corresponding .pl.tdy output file in the current working directory,
with the default permissions. In this specific scenario, using default
permissions for the temporary file in the current working directory
might not be considered a security problem. Apparently there are other
use cases in which an attacker might have read access to the temporary
file but lack read access to the .tdy file. It's not clear whether
addressing that had been a perltidy design goal.

(The general counterargument to the "always mode 600" principle is
that it had been historically common to have a multi-person
development effort with a strict policy that all files must always be
group-readable. If something goes wrong when one developer is working,
and it's the responsibility of a second developer to clean up at a
time when the first developer isn't available, then one might really
want all relevant information -- including any possible left-over
temporary files -- to be accessible to the second developer.)

> Is the POSIX module a core part of Perl, as in, the "return $name" part 
> will never be called?

It's conceivable that that depends on the version of Perl, but in any
case the answer doesn't affect how many CVE IDs are needed.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ