bugtraq - Re: [Full-Disclosure] 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: <20031124194633.E51549@dekadens.coredump.cx>
Date: Mon, 24 Nov 2003 19:58:17 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: Jakob Lell <jlell@...obLell.de>
Cc: full-disclosure@...ts.netsys.com, bugtraq@...urityfocus.com
Subject: Re: [Full-Disclosure] hard links on Linux create local DoS vulnerability
 and security problems

On Mon, 24 Nov 2003, Jakob Lell wrote:

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

Well, arguably, one can also just open() and hold a descriptor to other
guy's files to faciliate a similar attack in some conditions.

But yes, hardlinks introduce a whole array of security problems and other
brain-damage scenarios (a trivia: what happens if you create a hardlink to
/usr/bin/passwd in /tmp? 1: you cannot remove it; 2: if you name it
'r00tshell', the administrator would have a a heart attack upon spotting a
root-owned setuid binary in /tmp). This is hardly new - you can Google for
some BUGTRAQ discussions and such back in the '99 or so - but should be
brought up once in a while.

There are several ways to prevent this kind of abuse. Solar Designer's
patches, IIRC, allowed you to prevent the creation of certain hardlinks in
sticky-bit directories; properly setting default umask and permissions on
home directories and separation of /tmp, / and /home+/var prevents the
other issues (mount everything other than / as nosuid to prevent "setuid
archivization"). This is a common knowledge among those who maintain
larger shell servers, I suppose, but not necessarily well-known to the
general public.

Rant: the truth is, Linux and many other systems are just not very
suitable for providing shell-level accounts. Plenty of customizations
(advanced limits, custom PAM config, plenty of patches, smart partitioning
and other tweaks) are required to render the system even remotely secure
against local attacks targeting other unprivileged users - and even then,
it is usually possible to DoS the system or other users or cause other
inconvenience and security exposure. As such, I doubt this will get
noticed and patched.

Cheers,
-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-11-24 19:46 --

   http://lcamtuf.coredump.cx/photo/current/