full-disclosure - Re: hard links on Linux create local DoS vulnerability and security problems

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200311241931.19766.jlell@JakobLell.de>
From: jlell at JakobLell.de (Jakob Lell)
Subject: Re: hard links on Linux create local DoS vulnerability and security problems

On Monday 24 November 2003 19:17, Steven Leikeim wrote:
> On Mon, Nov 24, 2003 at 05:36:29PM +0100, Jakob Lell wrote:
> > Hello,
> > on Linux it is possible for any user to create a hard link to a file
> > belonging to another user. This hard link continues to exist even if the
> > original file is removed by the owner. However, as the link still belongs
> > to the original owner, it is still counted to his quota. If a malicious
> > user creates hard links for every temp file created by another user, this
> > can make the victim run out of quota (or even fill up the hard disk).
> > This makes a local DoS attack possible.
>
> Actually, this is a problem with ALL UNIX/UNIX like systems. And has been
> since the beginning.
>
> > To solve the problem, the kernel shouldn't allow users to create hard
> > links to files belonging to someone else.
>
> There is a simpler solution. Place user files on a separate filesystem
> from system files. This includes putting all temporary files on separate
> filesystems of their own. (Both /tmp and /var/tmp.) Since hard links
> cannot cross filesystems the problem disappears. Mounting user filesystems
> nosuid and nodev will prevent security problems should a setuid binary
> appear in that filesystem.

There are still many administrators which don't do this.
>
> Of course, this does not eliminate the first "DoS" problem noted above, but
> it is simple for an administrator to find where the extraneous links are
> and deal with the offending party.
This is no reason why it shouldn't be fixed. The victim can't solve the 
problem if the admin isn't available at the moment.