Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Mar 2011 07:19:10 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Pierre Joye <pierre.php@...il.com>
Cc: oss-security@...ts.openwall.com, 
	Helgi Þormar Þorbjörnsson <helgi@....net>
Subject: Re: CVE Request: PEAR Installer 1.9.1 <= - Symlink Attack

> Not sure it is fixable, or maybe using a lock on the symbolic link
> while fetching its target (to be tested to be sure that such locks
> cannot be overridden from shell).
>

The easiest way is to just open the target with the O_NOFOLLOW flag to
avoid following symlinks and abort on failure.  If you need to support
systems that don't have this flag, then perhaps you could consider
using an application-specific temporary directory instead of operating
in the world-writable /tmp.

>> Also, I don't see a reason why a hard link couldn't be used for exploitation
>> instead.
>
> Hard link are not detectable (lstat), they are treated like normal files.
>

Sure they are - just open the file, fstat() it, and check the st_nlink
field.  If it's more than one, you know there's hard linking going on.
 Sometimes this kind of check introduces a race condition of its own
where the file can be removed by the attacker after a file descriptor
is obtained but before the fstat(), but in this case since an attacker
would be creating a hard link to a victim's file, he wouldn't be able
to remove it since it's in a sticky-bit /tmp directory.

-Dan

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