[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201403090316.s293G8gL026877@linus.mitre.org>
Date: Sat, 8 Mar 2014 22:16:08 -0500 (EST)
From: cve-assign@...re.org
To: mmcallis@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com,
740670@...s.debian.org
Subject: Re: possible CVE requests: perltidy insecure temporary file usage
-----BEGIN PGP SIGNED MESSAGE-----
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
http://archives.neohapsis.com/archives/bugtraq/2000-02/0018.html 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:
http://cwe.mitre.org/data/definitions/378.html
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTG9yVAAoJEKllVAevmvms884IALYMJ4O0dcep0uIKRR84BIRZ
153u8FdoqUOSYQqQyowraXdpHYgSqkXjv2Rr/ATCIx//EehZU4nTRyBJ9Y5VtwCF
pncZZBz4cOzoKv2Q+7BjsIuU8PDz8wRR+1kXr1/lnyvtMRqUO49y2pzGbdSDGZs6
+TZ5/KjBiDMHGFUOV+wd9sWE1S4dV9h3CiipyL8WxAaaeAl95zZbEfSSDcXoWqI8
2CkXB03o4lUSvjvDkt07+zZn4R9a0BuFIM626spRlMO9H132KhCpF2Hc73px4sWl
xGjYfN1IE53JnhrMgKrzwcSzQXBXiCEPk+gMdTjqR+frcF4+RC29fwnjp1g7Afo=
=EM42
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
