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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Nov 2003 19:31:19 +0100
From: Jakob Lell <>
To: Steven Leikeim <>
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.

Full-Disclosure - We believe in it.

Powered by blists - more mailing lists