lists.openwall.net   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-next>] [day] [month] [year] [list]
Date: Mon, 24 Nov 2003 12:45:04 -0500
From: flaps@....toronto.edu (Alan J Rosenthal)
To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
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.

>To solve the problem, the kernel shouldn't allow users to create hard links to
>files belonging to someone else.

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.

>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.

ajr


Powered by blists - more mailing lists