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 attachment 42946 [details, diff] 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
