|
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.