Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: Re: any user can make hard links in Unix

Re: any user can make hard links in Unix

From: Bennett Todd <bet_at_RAHUL.NET>
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>
Received on Dec 22 1999

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos