Summary: | net-fs/davfs2: tmpfile bug / symlink attack | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Florian Schilhabel (RETIRED) <ruth> | ||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | minor | CC: | griffon26, net-fs, tklauser | ||||
Priority: | Highest | ||||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
URL: | http://dav.sourceforge.net | ||||||
Whiteboard: | B3 [glsa] koon | ||||||
Package list: | Runtime testing required: | --- | |||||
Attachments: |
|
Description
Florian Schilhabel (RETIRED)
2004-10-27 08:08:57 UTC
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 |