Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB43DE2.6030001@nixnuts.net>
Date: Fri, 04 Nov 2011 14:32:50 -0500
From: John Lightsey <john@...nuts.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: unsafe use of /tmp in multiple CPAN
 modules

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2011 01:14 PM, John Lightsey wrote:
> On 11/04/2011 11:36 AM, Solar Designer wrote:
>> On Fri, Nov 04, 2011 at 09:46:45AM -0500, John Lightsey wrote:
>>> File::Temp - _is_safe() allows unsafe traversal of symlinks
>>>
>>> https://rt.cpan.org/Public/Bug/Display.html?id=69106
>>
> 
>> 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 see the problem now.

Symlink A points to foo/bar
Symlink B points to /some/real/directory

Code asks for /tmp/parent/childXXXX

Attacker hardlinks symlink A to /tmp/parent
Attacker creates /tmp/foo directory
Attacker hardlinks symlink B to /tmp/foo/bar

Now everything looks safe, but it relies on the attacker controled
/tmp/foo directory.

It'd probably be simplest if File::Temp::_is_safe() didn't allow any
symlinks at all.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk60PdEACgkQBYeybkXz+/lTBQCfVSkNh3Rx//dXID4/EdZek2Oe
qI8AoNAmriAsRNAl9E1ji/aEb49Pj/8X
=B77I
-----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.