|
Message-ID: <AANLkTi=ze1G3WRwSM=nZHD_WTCshyka-TmUXAYOXw-VC@mail.gmail.com> 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.