Date: Mon, 14 Mar 2011 19:45:56 +0300 From: Vasiliy Kulikov <segoon@...nwall.com> To: oss-security@...ts.openwall.com Cc: Stephan Mueller <stephan.mueller@...ec.com> Subject: Re: Untrusted fs and invalid filenames On Mon, Mar 14, 2011 at 08:56 -0400, Dan Rosenberg wrote: > 1. An attacker convinces a victim to download an evil filesystem image > and manually mount it. > > 2. An attacker with physical access leverages automounting features to > cause the mounting of evil filesystems residing on external media. These two scenarios concern me. But I'd state it another way - it is not about an attacker trying to mount the image/flash drive, but a legitimate user wants to mount an _untrusted_ image/drive. He knows that it might be (or even _is_) malformed, how can he inspect the image securely? > The second case can be addressed > by restricting automounting in circumstances where it is > inappropriate, such as when the screen is locked. With model of a passive attacker explained above it doesn't help. > There have been far too many vulnerabilities in these types > of utilities to be worth the risk - I think distros should strip the > setuid bits from these helpers when possible, and otherwise ship these > helpers with 4750 permissions and restrict their execution to trusted > groups. I understand that FUSE must be an exception on some > distributions (such as Ubuntu), but other helpers (cifs, ncpfs, hgfs, > etc.) can probably be restricted a bit more. I completely agree here. But I don't see any limitation of FUSE - I don't want e.g. daemons to be able to mount images via FUSE. I'd like to have a group of real users, all other pseudo account must be very restricted. The whole idea of controlling the access to suid binaries is already implemented in owl-control - it is a small tool primarily targeted to restrict/relax suid/sgid binaries to different user sets like root only / special group / everybody; it was also ported to ALT Linux: http://docs.altlinux.org/manpages/control.8.html I see three potential attack targets: 1) Kernel code that works with partitions. 2) Filesystem code. 3) Userspace applications. As for (1) and (2) I'd agree with Steve Grubb about hardening fsck. It might be the cheapest way of controlling fs structs, especially taking into account that fsck already works with potentially corrupted partitions. The difference that it works with accidently corrupted data, we want it to work with malformed data. (3) includes filenames. Filenames charset may be filtered both on VFS side and application side. However, hardening every application that we would like to work on untrusted fs is unachievable idea, so moving some policy about allowable filenames charset to VFS looks reasonable for me. Smth like "fully relaxed" (no control at all) / "POSIX" (without ".", ".." filenames, '/' and '\0' inside) / "No special characters" (globs, etc.) / "Fully portable POSIX" (only "A–Za–z0–9._-") / customizable. Though, fully portable POSIX is not about security, but about another application of the restriction. Thanks, -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.