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]
Date: Mon, 24 Nov 2003 19:58:17 +0100 (CET)
From: Michal Zalewski <>
To: Jakob Lell <>
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.

------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * []
    Did you know that clones never use mirrors?
--------------------------- 2003-11-24 19:46 --

Powered by blists - more mailing lists