http://secunia.com/advisories/20078 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2542 xmcd-3.3.2 : /var/lib/xmcd is drwxr-wr-w /var/lib/xmcd/discog is drwxrwxrwx every local user can write to this directory. ** if the vulnerable directory is not empty (has been used by a user), "emerge -C xmcd" doesn't delete the vulnerable directory !! ** Debian has issue a big patch for this (DSA 1086-1) (concerning other issues as well). It might not be too difficult to patch our version (?)
you can see http://security.debian.org/pool/updates/main/x/xmcd/xmcd_2.6-14woody1.diff.gz
Would it be enough to make sure that the directories are 0755 in ebuild? both code and build system is a mess (imake), the less I have to deal with it the best (and the debian's patch is for a completely different version).
(In reply to comment #2) > Would it be enough to make sure that the directories are 0755 in ebuild? both > code and build system is a mess (imake), the less I have to deal with it the > best (and the debian's patch is for a completely different version). > i'm not sure. I'm afraid that the "0777" is fixed by the program itself, not only by the ebuild. I don't have time to investigate into this atm.
An ebuild patch seems to be sufficient, in pkg_postinst(), AFAICT looking at the debian patch +chown -R root.audio /var/lib/cddb +find /var/lib/cddb -type d -print0 | xargs -0r chmod 3775 +# permissions used to be 666! +chmod -R o-w /var/lib/cddb
Falco is this one ready for ebuild status?
(In reply to comment #5) > Falco is this one ready for ebuild status? > I think an ebuild patch will be enough, in pkg_postinst(). But i would like to receive a confirmation.
Any news on this one?
sound team please advise
(In reply to comment #8) > sound team please advise I can confirm that the directory is world writable... /var/lib/xmcd/ drwxr-xr-x root root /var/lib/xmcd/discog drwxrwxrwx root root Patching the ebuild in pkg_postinst() with this seems to work... + chown -R root.audio /var/lib/xmcd + find /var/lib/xmcd -type d -print0 | xargs -0r chmod 3775 + # permissions used to be 666! + chmod -R o-w /var/lib/xmcd New permissions... /var/lib/xmcd/ drwxrwsr-t root audio /var/lib/xmcd/discog drwxrwsr-t root audio I haven't bumped this in portage yet because I cannot get xmcd working to test it. It has a strange wrapper script ( /usr/X11R6/lib/X11/xmcd/bin-*/start ) which needs to be run to setup the env, but it keeps complaining saying that I need to own the CD-ROM device or have /usr/X11R6/lib/X11/xmcd/bin-*/{xmcd,cda} setuid. I chown'd /dev/cdrom and /dev/hdc and set both of the files setuid, but it still would not start. It doesn't work when I try it as root either. Can someone from the sound team please test xmcd with the ebuild change mentioned above to make sure that xmcd still functions properly and doesn't change the permissions of /var/lib/xmcd/* back? Then, please commit the ebuild change above.
Sound please advise.
(In reply to comment #11) > Sound please advise. I can't get xmcd to work (see comment #9). Unless someone from the sound team who has more knowledge about it than me steps up, I would suggest masking and removing it.
I suggest masking this one, comments?
Security/Sound any comments?
sound team, is there a reason this trivial fix hasnt been committed yet?
(In reply to comment #15) > sound team, is there a reason this trivial fix hasnt been committed yet? Because I can't get xmcd working to test it (see Comment #9) and no one from the sound team is interested in this package.
Ok, then I think we should mask it. Security do you agree?
Definitely. Autocount frilled++ on masking .-)
This package is dead upstream, nobody seems to care about maintaining it here, and the only updates have been virtual x, and similar. It is not a dependency for any other package. I've removed it from portage.
Time for late GLSA decision on this one. I tend to vote NO.
NO also.
No++.
Closing without GLSA.
