[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110314164556.GA6772@albatros>
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.
