lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Nov 2003 19:19:40 +0100
From: Casper Dik <>
To: (Alan J Rosenthal)
Subject: Re: hard links on Linux create local DoS vulnerability and security problems

>>on Linux it is possible for any user to create a hard link to a file belonging
>>to another user.
>Only if they can write to some directory on the same partition.
>>Furthermore, users can even create links to a setuid binary.
>Only if it's on the same partition.  This is just one of a huge number of
>reasons you shouldn't allow users to write to your root or /usr partitions.
>I think that your observation of the ability to keep a security hole open is
>very interesting, but, fortunately, it should be moot.

Many (older) recipies for replacing set-uid binaries consisted of:

	mv /usr/bin/buggy /usr/bin/buggy.old
	chmod 0 /usr/bin/buggy.old

so it's certainly possible to work around that problem.

>I think that this is too drastic a change to the semantics of the unix
>filesystem.  Except for the kludge around the sticky bit, nothing about
>creation and deletion of files (links) depends upon the permissions on the
>file itself, just on the enclosing directory.

But it can't be denied that hard links to files one doesn't
own pose some interesting challenges; not just in the scope
of quotas but also when it comes to actions users cannot
undo (such as making many links to files belonging to other
users in /tmp)

>>If you can check whether this problem also exists on other unix-like
>>operating systems, please post the results.
>It certainly does.  This is part of the original design of the unix
>filesystem.  Creating a link requires write access to the directory you're
>creating it in, not to the file you're linking to.
>I think that if a user creates a bunch of hard links to someone else's
>temporary files, the evidence should point to the original user, on a typical
>well-maintained unix system.  The link to setuid programs is more of concern
>except that it won't be able to happen unless you have setuid-root programs
>in a home directory partition, which sounds bad anyway.

And you can easily work around it when replacing executables.


Powered by blists - more mailing lists