Logfile symlink vulnerability

[Eran Tromer]

Harold L Hunt II wrote:

> With two distinct users, not in the same group, and with neither an
> administrator?
> What OS was this with? Were you using NTFS or FAT32?
> Please provide more details of your test.

Windows XP, NTFS drive. Two different users; the attacker is a
"restricted user", the victim is an administrator. The attacker runs
"ln -s /home/victim/foo /tmp/XWin.log" and then the victim runs "XWin
badarg" and beholds his ~/foo being overwritten.

> I just don't see how you could overwrite a file at all if you don't
> have premission on the underlying filesystem...

All the attacker user does is create /tmp/XWin.log as a symbolic link.
It's the victim which performs the actual damage, by following the
symbolic link to one of its *own* files and overwriting it. The only
permissions involved are /tmp being world-writable (it doesn't even
matter that /tmp had the sticky bit, if /tmp/XWin.log didn't exist
beforehand).

It's really a classical Unix security pitfall that occurs whenever you
write to files in world-writable directories. It has to be dealt with at
the application level, either by being careful about existing files or
by using atomically generated unique filenames.

  Eran