Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 04 Nov 2011 13:14:46 -0500
From: John Lightsey <>
Subject: Re: CVE request: unsafe use of /tmp in multiple CPAN

Hash: SHA1

On 11/04/2011 11:36 AM, Solar Designer wrote:
> On Fri, Nov 04, 2011 at 09:46:45AM -0500, John Lightsey wrote:
>> PAR::Packer - PAR packed files are extracted to unsafe and predictable
>> temporary directories
> I think that your description for this one happens to encourage a poor
> fix for it.  Specifically, starting the description by "par_mktmpdir()
> makes no effort to verify that the /tmp/par-<username> directory is safe
> to use" may result in this function being patched to do such checks,
> which I think would be a poor fix.  A better fix would be to properly
> create a temporary files directory, with a less predictable name and
> with due retries (with new names) if the directory already exists -
> preferably using File::Temp's tempdir().

The problem with using random directory names here is that the
/tmp/par-user directory is being used as a caching mechanism to avoid
extracting the PAR contents over and over. A better alternative may be
to use $ENV{'HOME'}/.par or something along those lines.

>> File::Temp - _is_safe() allows unsafe traversal of symlinks

> As to the proposed fix (symlink-safety.patch), it partially helps in
> certain special misuse cases.  Namely, when the pathname is not
> untrusted/malicious, but is poorly chosen, yet it contains just one
> unsafe component.  However, even in that case this fix doesn't protect
> from hard-linking of an existing suitable symlink (of a trusted user)
> into /tmp (possibly under a different name, although the symlink target
> name remains that of the original symlink).  And the limitation of
> working for just one unsafe path component is no good; perhaps HIGH's
> checks of parent directories would be better enabled unconditionally,
> and even then this stuff is highly questionable.

I'm not sure I follow how that would work as an attack vector. If I
hardlink a symlink of another user into /tmp, I can't easily remove the
symlink afterwards to point it somewhere else. If _is_safe() checks the
ownership of the symlink and the ownership of the symlink target it
would be very difficult to misuse a symlink in this fashion.

I would definitely agree that using File::Temp is preferable to someone
implementing custom /tmp handling logic. Most of the CPAN code that
messes with /tmp directly should be using File::Temp instead.

I've not seen any code on CPAN uses File::Temp to create nested
subdirectories in the fashion that would be required for an unsafe
intermediate symlink to be a problem. IE: /tmp/foo/barXXXXX with
/tmp/foo being the unsafe symlink.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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.