Follow @Openwall on Twitter for new release announcements and other news
[<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

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.