Vulnerability Development mailing list archives
Re: any user can make hard links in Unix
From: bet () RAHUL NET (Bennett Todd)
Date: Wed, 22 Dec 1999 12:12:42 -0500
This may be an issue, of the form "lots of people might not know about this, and understand its implications, so people might design systems that are buggy because of this feature". But I don't see any deep security problem here. Taking your points one by one: 1999-12-21-21:36:54 Benjamin Elijah Griffin:
1) If the user has read access to the writable directory, s/he can now stat the inode even if the original location did not offer read access.
They had to have stat access to the original inode to make the hard link. All that is required to stat an inode (or for that matter to read a file, if its permissions allow) is _execute_ permission in the containing directory (and parents up to the root), not read permission. Read permission on a directory is only needed to read the directory itself, to find out what files are in it. If you already know the filename then execute permission is enough. If you can hard link to it, you can stat it already.
2) The user can change the ctime of the inode (fun with tripwire).
So don't use tripwire. I'm very happy with the protection provided by the MD5 checksums in binary RPMs, stored offline from the system they're installed on.
3) Some suid programs that just checked for sym-links can perhaps be duped into opening or writing to files they shouldn't. 4) Social hacks involving 'chown -R' or the like.
These fall into the category I described in the beginning: not a problem with the OS feature, but a problem that could be caused because people don't know about it.
5) Screw with the quota of other users and other ways to make it hard to delete files that should be deleted (eg large logs in /var)
Yup, there are ways to mess people up using the ability to hard-link to their files. Fortunately the messes go away when the hard links are removed, and until they're removed there's at least the hope of tracking the offender down. The biggest thing that this reveals is that it's absolutely mandatory to segregate world-writeable directories on their own partitions. If you don't have a world-writeable directory on the same partition as the file, then the attacker will own the containing directory where they make the hard link, so if anybody plays silly games with hard links you can hunt 'em down and suitably chastize them. -Bennett <HR NOSHADE> <UL> <LI>application/pgp-signature attachment: stored </UL>
Current thread:
- Re: ssh quirks..., (continued)
- Re: ssh quirks... Ryan Permeh (Dec 27)
- Re: ssh quirks... Scott D. Yelich (Dec 27)
- Re: ssh quirks... C.J. Oster (Dec 27)
- Re: ssh quirks... Blue Boar (Dec 27)
- Re: ssh quirks... Ralph the Wonder Llama (Dec 27)
- Re: ssh quirks... LaMont Jones (Dec 27)
- Re: ssh quirks... Kev (Dec 28)
- Re: ssh quirks... Mark Rafn (Dec 28)
- Re: BSD chfn bug Warner Losh (Dec 27)
- any user can make hard links in Unix Benjamin Elijah Griffin (Dec 21)
- Re: any user can make hard links in Unix Bennett Todd (Dec 22)
- A Bug in the Recently Released BetaFTPD0.0.8pre7 (fwd) Bubonic (Dec 21)
- Possible MultiNet FTP server DoS problem. CyberPsychotic (Dec 21)
- Re: Possible MultiNet FTP server DoS problem. Lisa Napier (Dec 23)
- MSIE print feature Anonymous Anonymous (Dec 24)
- procmail / Sendmail - five bugs Michal Zalewski (Dec 23)