Bugzilla Bug 69149

net-fs/davfs2: tmpfile bug / symlink attack

hi,
i have found a tmpfile/symlink bug in net-fs/davfs2:
the affected function is in utility.c:

-- snip [utility.c] --

int dav_save_mount_pid(const char *dev) {
    char *fname = ne_concat(DAV_TMP_DIR, dev+5, ".pid", NULL);
    FILE *fp = fopen(fname, "w");
    NE_FREE(fname);

    if(fp==NULL) {
	perror(fname);
	return -1;
    }

    fprintf(fp, "%d", getpid());
    fclose(fp);

    return 0;
}

-- snip --

DAV_TMP_DIR extracts simply to /tmp;
therefore, mount.davfs creates the following pidfile:
/tmp/davfs0.pid
unfortunately, the program doesn't check, if this file already exists or if it is a symlink; if the file exists(also as symlink), it simply gets truncated to zero lenght...
so issuing a:
ln -sf /etc/[insert_your_favourite_file_here] /tmp/davfs0.pid
usually results in a severe system failure
as mount.davfs is usually invoked as root; an attacker can overwrite virtually every file on a system.

solution:

check the existence of the pidfile, place the pidfile in /var/run, for example.

note, that i didn't yet contact the authors about this issue.
as the latest cvs entry is about 8 weeks old, i assume, this project is still alive and the bug can be (and should be) fixed upstream.

best regards
florian [rootshell]

Audit team, please double-check :)

requesting comments...

Are you able to provide a patch to correct the problem?

Created an attachment (id=42946) [details]
davfs2-0.2.2-pid.patch

This patch should mitigate the problem by using /var/run as it's default
storage dir for *.pid files. Assuming that /var/run is mode_t 755 root:root

Sent upstream. 

Robert Spier replied:

I've applied the patch -- which looked good -- to the latest CVS and
quietly rolled a 0.2.3 release.  (Sung, it's only lightly tested --
but nobody seems to have complained about CVS HEAD recently.)

I don't see a reason from our side to make a huge deal out of this --
I'm not trying to cover it up -- but there aren't that many davfs2
users (and it's probably decreasing daily).  Because if it's
"stability" -- most of them probably aren't running it on a multi-user
system.

Thanks for spotting and fixing this Florian and Ned, respectively

Can someone roll an updated ebuild? Do we still want to keep this quiet and report it to vendor-sec?

No maintainer... We'll have to bump ourselves

A patched version of davfs2-0.2.2-r1 now exists in the tree.  (no other vendor
made aware of this)

davfs2-0.2.1.ebuild:KEYWORDS="x86"
davfs2-0.2.2-r1.ebuild:KEYWORDS="~x86 ~ppc"
davfs2-0.2.2.ebuild:KEYWORDS="~x86 ~ppc"

x86: please test and mark davfs2-0.2.2-r1 stable

testing this requires having coda in the kernel.. is there someone from net-fs
that is on x86 who can test this? (I dont think anyone on x86@ does..)

Maurice - the coda guy!

I tested and confirmed that the latest version creates /var/run/davfs0.pid and
that it does not create /tmp/davfs0.pid, nor meddle with it if it is present 
(as a file or as a symlink). These are the only tests I performed.

However, I was unable to build davfs without applying Tobias Klauser's 
kernel-headers patch for bug #62502! Therefore I did not mark it stable.

What should we do with this?

Two solutions : apply the patch to 0.2.1 as well, or wait for bug 62502 to be
fixed.

Since it's going to take a little time, I unlink the other tempfile bugs from
this one.

Other vendors made aware via the vendor-sec mailing list.

if nobody else has, i'll look into the 2.6 compilation problems tomorrow

brad already has in bug #62502

Here is one suggestion, see what you do with it:

- Mark 0.2.2-r1 stable right now (even though it doesn't compile for everyone) to 
  make sure that current users get the security fix ASAP without the risk of 
  breakage caused by the compile-on-2.6 fix.
- Then decide if we want to keep it or not. We could mail around for a maintainer
  and mask it after a while if nobody steps up.

I am not sure issuing a GLSA asking people to upgrade and have it fail on all
2.6 users is a good solution...

There are easier ones : we wait for the other bug to be solved (this is not a
critical vulnerability anyway), or someone (from net-fs) applies the patch to
0.2.1 and produces a 0.2.1-r1 that we will mark stable. Patching works :

---------------------------------------------
patching file src/util.c
Hunk #1 succeeded at 259 (offset -22 lines).
Hunk #2 succeeded at 279 (offset -22 lines).
patching file src/util.h
---------------------------------------------

I would choose the second solution. But until someone does (I can't, no commit
rights yet) we'll be in the first solution :)

Maybe I wasn't clear about this. The security fix doesn't break anything.
If people have managed to install the vulnerable version, they will be
able to install the patched versions. People who couldn't compile before
won't be able to now, but they don't need the fix anyway.

Ah OK. I thought that bug 62502 was 0.2.2-specific. Since it's not the case,
then you should mark stable 0.2.2-r1 as it brings no regression since the
current stable (policy is we should mark stable for security reasons if there
is no regression between the latest stable version and the new one, even if
there are known bugs in both cases).

So please mark 0.2.2-r1 "stable" as in "not worse than the latest stable, and
more secure" :)

I marked davfs2-0.2.2-r1 stable now, so that closes this bug. 
Any fixes for compilation problems can be done later for #62502.

Ready for a GLSA then

Group GLSA with bug 68406

davfs 0.2.3 was released by upstream. See bug #70692 for details.

GLSA 200411-22