Date: Sun, 2 Jun 1996 00:13:43 -0700 (PDT) From: "Chris J. Layne" <coredump@nervosa.com> To: freebsd-security@freebsd.org Subject: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd) Message-ID: <Pine.BSF.3.91.960602001233.4187A-100000@onyx.nervosa.com>
next in thread | raw e-mail | index | archive | help
Could this have any impact on our implementation of ext2fs? == Chris Layne ======================================== Nervosa Computing == == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Thu, 30 May 1996 21:20:46 +0100 (BST) From: Zefram <A.Main@dcs.warwick.ac.uk> To: linux-security@tarsier.cv.nrao.edu Subject: [linux-security] ext2fs file attributes -- denial-of-service attack All versions so far of the second extended file system (ext2fs) as implemented in the Linux kernel have the following security problem. Any user is permitted to set any file attribute other than `immutable' on files they own. In particular, an unprivileged user can set the `append-only' flag. To do this merely requires the ability to execute arbitrary code -- the flag is set by an ioctl(2) call. The usual way to set these flags is by use of the chattr(8) command. The effects of the append-only flag being set on a file are o No process, even with privileges, may open the file other than in append mode. The file cannot be truncated. o No process, even with privileges, may use link(2), unlink(2) or rename(2) on the file. The flag can be set on a directory in the same way, in which case o No process, even with privileges, may use rename(2) or rmdir(2) on the directory. o No process, even with privileges, may use rename(2), rmdir(2) or unlink(2) on any entry in the directory. The only differences between the effects of the append-only flag and the immutable flag are that an append-only file may be appended to (whereas an immutable file cannot be opened for writing at all), and an append-only directory may have new entries added to it (whereas an immutable directory can't be modified at all). Note that the immutable flag, because of its extensive effects, can only be set by a privileged process, but the append-only attribute, with most of the same effects, can be set by the owner of the file in question, even if unprivileged. Obviously there are denial-of-service attacks based on this. The most obvious attack is to create a very large file in /tmp and make it append-only -- any root-run program intended to clear /tmp will fail unless it knows to remove the flag. Even if it does know, there is a race condition, as the flag cannot be cleared simultaneously with deletion, but in this case much the same effect could be obtained by merely keeping the file open. Another possible use of this file attribute is to prevent a symbolic link being removed, making some symlink-based attacks that rely on race conditions work deterministically. This is only possible if the attacker owns the directory containing the symlink. In general, anywhere a privileged process assumes it can remove or rename a file owned by any user, that assumption is rendered incorrect if the user can access the file to set the flag. The only possible solution is to modify the semantics of the append-only attribute in the kernel. There are three likely approaches: (1) setting the append-only flag can be limited to privileged processes; (2) the linking-related effects of the flag can be removed, bringing it in line with the description in the chattr man page; (3) the effects of the flag could be made to have no effect on privileged processes. (3) opens some security holes itself, but should be borne in mind. I produced a patch implementing (2) some time ago, but it the relevant kernel developers say that (1) is the preferred approach. -- Andrew Main <zefram@dcs.warwick.ac.uk>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960602001233.4187A-100000>