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

Message-ID: <200311241736.29572.jlell@JakobLell.de>
Date: Mon, 24 Nov 2003 17:36:29 +0100
From: Jakob Lell <jlell@...obLell.de>
To: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
Subject: hard links on Linux create local DoS vulnerability and security problems

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.

Furthermore, users can even create links to a setuid binary. If there is a 
security whole like a buffer overflow in any setuid binary, a cracker can 
create a hard link to this file in his home directory. This link still exists 
when the administrator has fixed the security whole by removing or replacing 
the insecure program. This makes it possible for a cracker to keep a security 
whole open until an exploit is available. It is even possible to create links 
to every setuid program on the system. This doesn't create new security 
wholes but makes it more likely that they are exploited.

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

I could reproduce the problem on linux 2.2.19 and 2.4.21 (and found nothing 
about it in the changelogs to 2.4.23-rc3). If you can check whether this 
problem also exists on other unix-like operating systems, please post the 
results.

Regards
 Jakob