symlink attack vuln in hb
(too old to reply)
Przemysław Czerpak
2010-06-02 04:05:43 UTC
On Wed, 02 Jun 2010, Szak�ts Viktor wrote:

Hi Viktor and Tamas,

The security problem with links appears when any file is open
for writing and previous contents of the file is not released
so application cannot use 'unlink' and O_EXCL flag (or workarond
with 'link' for race condition in old NFS <= 3.0 protocols).
BTW for security reasons we should have such code

The idea with copping the file original file body to new one
when log is created does not resolve the problem but replace
it with the new one even worser, i.e.:
ln -s /ets/shadow /tmp/hb_out.log
and I can read encrypted passwords for brutal force attack.
Of course any soft links can be eliminated by using O_NOFOLLOW
open() flag on systems which support it but it does not help
for hard links so the problem still exists (good admins used
to keep vital system files on separate partitions without any
write access for users so they cannot create any hard links)
but we can try to make farther protection and use fstat() to
check number of links. It's still not perfect because we have
race condition which cracker may try to exploit but if we can
compare fstat() results with stat() results to be sure we are
talking about the same file. It's efficient solution for systems
which supports O_NOFOLLOW but this is not POSIX flag and some
older *nixes may not have it. If you want then I can add such

All programs opening/creating files have such problems and it's
programmer job to create application protected against such attack,
i.e. my production applications drop root privileges switching to
some other user and group ID. In this particular case we are talking
about hb_out.log files created when harbour application crashes so
it's not sth what should appear in production code but it cannot
be excluded.

best regards,