(In reply to comment #0)
> A few more fixes have made their way to FUSE to prevent TOCTTOU symlink
> attacks. An unprivileged user was able to unmount arbitrary mounts:
> 
> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=bf5ffb5fd8558bd799791834def431c0cee5a11f

This a new issue, yes.

> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1e7607ff89c65b005f69e27aeb1649d624099873

This is not a security fix, AFAICS.

> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=cbd3a2a84068aae6e3fe32939d88470d712dbf47

And this CVE-2010-3879 (bug 651598)

(In reply to comment #1)
> > http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=cbd3a2a84068aae6e3fe32939d88470d712dbf47
> 
> And this CVE-2010-3879 (bug 651598)

This moves and removes code. Is this required to actually fix CVE-2010-3879 or is it just cleanup?

(In reply to comment #2)
> (In reply to comment #1)
> > > http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=cbd3a2a84068aae6e3fe32939d88470d712dbf47
> > 
> > And this CVE-2010-3879 (bug 651598)
> 
> This moves and removes code. Is this required to actually fix CVE-2010-3879 or
> is it just cleanup?

This is a fix for HEAD that already had a broken fix for CVE-2010-3879.

But the packages submitted for bug 651598 are not based on HEAD, it's an independent patch and should be OK.

http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=bf5ffb5fd8558bd799791834def431c0cee5a11f

Fuse tries to mount a directory without resolving symlinks, and then
tries to update mtab. If it couldn't update mtab, it would unmount the
directory while resolving symlinks this time, resulting in a different
directory being unmounted.

http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1e7607ff89c65b005f69e27aeb1649d624099873

This prevents local users from changing the location of the current
directory from under fuse using a timing attack.

http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=cbd3a2a84068aae6e3fe32939d88470d712dbf47

Fuse uses the --no-canonicalize mount option to prevent a symlink attack
on the mount point written to mtab. For backwards compatibility reasons,
it would fallback to using mount in an insecure way. This fallback could
get triggered by a user when an entry already existed in mtab.


All three of these issues allowed local users to trick fuse into
unmounting arbitrary directories.

p5->p3 mass change

> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1e7607ff89c65b005f69e27aeb1649d624099873
> 
> This prevents local users from changing the location of the current
> directory from under fuse using a timing attack.

Not sure what you mean?  The location of the CWD should be irrelevant at that point.  I looked at a strace now, and "mount --no-canonicalize ..." indeed ignores the CWD completely.  Doing that chdir("/") is for defensive reasons, not because there was any specific problem with not doing it.

(In reply to comment #6)
> > http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1e7607ff89c65b005f69e27aeb1649d624099873
> > 
> > This prevents local users from changing the location of the current
> > directory from under fuse using a timing attack.
> 
> Not sure what you mean?  The location of the CWD should be irrelevant at that
> point.  I looked at a strace now, and "mount --no-canonicalize ..." indeed
> ignores the CWD completely.  Doing that chdir("/") is for defensive reasons,
> not because there was any specific problem with not doing it.

I am sorry for causing confusion. This was not my statement, just a copy-and-paste for the oss-security ML.

Re: [oss-security] CVE request: fuse
 Von: Josh Bressers <bressers@redhat.com>
 An: oss-security@lists.openwall.com
 Kopie: coley <coley@mitre.org>
 
Sorry for the dealy, some other things popped up :(

I'm going to assign 3 IDs. These look like they maybe could be combined,
but I'd rather not try to just to have a big split later on when we find
out various versions are affected in different ways.

> 
> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=bf5ffb5fd8558bd799791834def431c0cee5a11f
> 
> Fuse tries to mount a directory without resolving symlinks, and then
> tries to update mtab. If it couldn't update mtab, it would unmount the
> directory while resolving symlinks this time, resulting in a different
> directory being unmounted.

Use CVE-2011-0541


> 
> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=1e7607ff89c65b005f69e27aeb1649d624099873
> 
> This prevents local users from changing the location of the current
> directory from under fuse using a timing attack.

Use CVE-2011-0542


> 
> http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=cbd3a2a84068aae6e3fe32939d88470d712dbf47
> 
> Fuse uses the --no-canonicalize mount option to prevent a symlink attack
> on the mount point written to mtab. For backwards compatibility reasons,
> it would fallback to using mount in an insecure way. This fallback could
> get triggered by a user when an entry already existed in mtab.
> 

Use CVE-2011-0543

Thanks.

-- 
    JB

Submitted fixes for CVE-2011-0541:

SUSE:SLE-11-SP1:Update:Test (sr#10796)
SUSE:SLE-10-SP3:Update:Test (sr#10797)
openSUSE:11.3:Update:Test (sr#62399)
openSUSE:11.2:Update:Test (sr#62400)
openSUSE:Factory (sr#62403)

CVE-2011-0543 is already fixed in the current repository under the designation of bnc#651598.

As for CVE-2011-0542, I don't see that it's a security issue.

Reassigning to security team.

Hello Miklos,
your patch fuse-fix-cleanup-in-case-of-failed-mount.patch seems to be different from the upstream patches. It just removes umount which makes "problematic" mounts unremovable. Is this intended?

Hello Thomas,

Yes it's intended.  After more thoroughly testing the upstream patch, it turns out that it didn't work as intended, failing the umount() with -EINVAL.

I thought about it long and hard, and concluded that there's no sane solution to this, so I'm going with the simple fix of just removing the problematic umount() call.

Update released for: fuse, fuse-debuginfo, fuse-debugsource, fuse-devel, libblkid-devel, libblkid-devel-32bit, libblkid1, libblkid1-32bit, libblkid1-x86, libfuse2, libuuid-devel, libuuid-devel-32bit, libuuid1, libuuid1-32bit, libuuid1-x86, util-linux, util-linux-debuginfo, util-linux-debugsource, util-linux-lang, uuid-runtime
Products:
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)

Update released for: fuse, fuse-debuginfo, fuse-debugsource, fuse-devel, fuse-devel-static, libblkid-devel, libblkid1, libblkid1-debuginfo, libfuse2, libfuse2-debuginfo, libuuid-devel, libuuid1, libuuid1-debuginfo, util-linux, util-linux-debuginfo, util-linux-debugsource, util-linux-lang, uuidd, uuidd-debuginfo
Products:
openSUSE 11.2 (debug, i586, x86_64)

Update released for: fuse, fuse-debuginfo, fuse-debugsource, fuse-devel, fuse-devel-static, libblkid-devel, libblkid1, libblkid1-debuginfo, libfuse2, libfuse2-debuginfo, libuuid-devel, libuuid1, libuuid1-debuginfo, util-linux, util-linux-debuginfo, util-linux-debugsource, util-linux-lang, uuidd, uuidd-debuginfo
Products:
openSUSE 11.3 (debug, i586, x86_64)

released

Update released for: fuse, fuse-debuginfo, fuse-devel, libfuse2, util-linux, util-linux-debuginfo
Products:
SLE-DEBUGINFO 10-SP3 (i386, ia64, ppc, s390x, x86_64)
SLE-DESKTOP 10-SP3 (i386, x86_64)
SLE-SAP-APL 10-SP3 (x86_64)
SLE-SDK 10-SP3 (i386, ia64, ppc, s390x, x86_64)
SLE-SERVER 10-SP3 (i386, ia64, ppc, s390x, x86_64)

Update released for: fuse, fuse-debuginfo, fuse-devel, libfuse2
Products:
SLE-DESKTOP 10-SP4 (i386, x86_64)
SLE-SDK 10-SP4 (i386, ia64, ppc, s390x, x86_64)

*** Bug 685055 has been marked as a duplicate of this bug. ***

*** Bug 685055 has been marked as a duplicate of this bug. ***