Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 69149 - net-fs/davfs2: tmpfile bug / symlink attack
Summary: net-fs/davfs2: tmpfile bug / symlink attack
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: Highest minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa] koon
Depends on:
Reported: 2004-10-27 08:08 UTC by Florian Schilhabel (RETIRED)
Modified: 2004-11-11 13:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

davfs2-0.2.2-pid.patch (davfs2-0.2.2-pid.patch,1.21 KB, patch)
2004-10-30 19:41 UTC, solar (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Schilhabel (RETIRED) gentoo-dev 2004-10-27 08:08:57 UTC
net-fs/davfs2: tmpfile bug / symlink attack

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");

    if(fp==NULL) {
	return -1;

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

    return 0;

-- snip --

DAV_TMP_DIR extracts simply to /tmp;
therefore, mount.davfs creates the following pidfile:
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/
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.


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]
Comment 1 Thierry Carrez (RETIRED) gentoo-dev 2004-10-27 08:35:25 UTC
Audit team, please double-check :)
Comment 2 Florian Schilhabel (RETIRED) gentoo-dev 2004-10-30 17:21:29 UTC
requesting comments...
Comment 3 solar (RETIRED) gentoo-dev 2004-10-30 18:06:15 UTC
Are you able to provide a patch to correct the problem?
Comment 4 solar (RETIRED) gentoo-dev 2004-10-30 19:41:32 UTC
Created attachment 42946 [details, diff]

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
Comment 5 Dan Margolis (RETIRED) gentoo-dev 2004-11-01 10:51:58 UTC
Sent upstream. 
Comment 6 Dan Margolis (RETIRED) gentoo-dev 2004-11-01 22:09:45 UTC
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

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?
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2004-11-02 05:55:47 UTC
No maintainer... We'll have to bump ourselves
Comment 8 solar (RETIRED) gentoo-dev 2004-11-03 06:49:23 UTC
A patched version of davfs2-0.2.2-r1 now exists in the tree.  (no other vendor made aware of this)

davfs2-0.2.2-r1.ebuild:KEYWORDS="~x86 ~ppc"
davfs2-0.2.2.ebuild:KEYWORDS="~x86 ~ppc"
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2004-11-03 07:13:46 UTC
x86: please test and mark davfs2-0.2.2-r1 stable
Comment 10 Olivier Crete (RETIRED) gentoo-dev 2004-11-05 16:50:43 UTC
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..)
Comment 11 Daniel Black (RETIRED) gentoo-dev 2004-11-06 06:58:01 UTC
Maurice - the coda guy!
Comment 12 Maurice van der Pot (RETIRED) gentoo-dev 2004-11-06 07:36:16 UTC
I tested and confirmed that the latest version creates /var/run/ and
that it does not create /tmp/, 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?
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2004-11-07 10:25:48 UTC
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.
Comment 14 solar (RETIRED) gentoo-dev 2004-11-07 11:25:31 UTC
Other vendors made aware via the vendor-sec mailing list.
Comment 15 Daniel Drake (RETIRED) gentoo-dev 2004-11-07 12:17:01 UTC
if nobody else has, i'll look into the 2.6 compilation problems tomorrow
Comment 16 Maurice van der Pot (RETIRED) gentoo-dev 2004-11-07 12:22:46 UTC
brad already has in bug #62502
Comment 17 Maurice van der Pot (RETIRED) gentoo-dev 2004-11-07 12:26:33 UTC
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.
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2004-11-09 04:32:51 UTC
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 :)
Comment 19 Maurice van der Pot (RETIRED) gentoo-dev 2004-11-09 04:48:47 UTC
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.
Comment 20 Thierry Carrez (RETIRED) gentoo-dev 2004-11-09 05:17:28 UTC
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" :)
Comment 21 Maurice van der Pot (RETIRED) gentoo-dev 2004-11-09 13:31:19 UTC
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.
Comment 22 Thierry Carrez (RETIRED) gentoo-dev 2004-11-09 13:33:11 UTC
Ready for a GLSA then
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2004-11-10 01:16:57 UTC
Group GLSA with bug 68406
Comment 24 tklauser 2004-11-10 11:09:41 UTC
davfs 0.2.3 was released by upstream. See bug #70692 for details.
Comment 25 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-11-11 13:29:03 UTC
GLSA 200411-22