Date: Mon, 3 Jun 1996 05:59:38 +1000 From: Bruce Evans <bde@zeta.org.au> To: coredump@nervosa.com, freebsd-security@freebsd.org Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd) Message-ID: <199606021959.FAA04887@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Could this have any impact on our implementation of ext2fs? Not directly. The ext2fs append and immutable flags have ufs semantics under FreeBSD, and the other ext2fs flags have no effect under FreeBSD. However, the ext2fs semantics seem to be the same as the the ufs ones for the common flags, so the bug report may have an impact on CSRG's implementation of ufs :-). There are some implementation bugs in our ext2fs that reduce the problem for our ext2fs. ufs has both user and system immutable and append flags but ext2fs (apparently) has only a system immutable flag and a shared append flag. The ext2fs flags are each mapped to the (user|system) combination of ufs flags, and ext2fs uses ufs_setattr() and ufs_getattr() without special handling for the ext2fs flags. Thus it is possible to fchflags() the flags in the vnode to an unrepresentable value and see the wrong value using fstat(), but denial of service attacks and writing to your own append-only files are prevented by the system append flag being set. >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. 4.4Lite has a cleaner implementation involving the chflags(2) and fchflags(2) syscalls, and a more naturally named chflags(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). This is all the same as in 4.4Lite. >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. 4.4Lite has a separate immutable for users, so the denial of service problems (if any) apply to the immutable flag too. It has a separate append flag for users, so the semantics are clearer and fixing the problem by restricting access is equivalent to dropping support for the user flags. >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 Root had better know how to clear flags using chflags -R. FreeBSD's `rm' has been hacked to unconditionally turn off the user append and immutable flags before attempting removals. 4.4Lite2's rm still fails to remove user-append/immutable files. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606021959.FAA04887>