While converting git.eclass to git.exlib for exherbo, zlin discovered that subversion.eclass, mercurial.eclass and git.eclass have been setting o+rw permissions on DISTDIR/{svn,git}-src for a long time. The bug started in subversion.eclass and slipped into git.eclass when we converted it. subversion: Bug entered in revision 1.5. Gone in r1.33. git: Entered in revision 1.1. Gone in 1.10. mercurial: Entered in revision 1.1. Gone: See bug #151063 I checked darcs, tla and cvs. They all seem ok. This opens a wide range of attacks. People shoudn't trust anything beneath the DISTDIR/*-src directories created by those eclasses. - ferdy
GLSA filed.
As for a GLSA, I would have expected there are no stable packages affected by this. Unfortunately, they exist, which is really bad. Only for SVN: =sci-chemistry/pymol/pymol-0.99_rc10 And a lot of MythTV is checked out from SVN, I did not yet check all of them. media-plugins/mytharchive/mytharchive-0.20.2_p14807 media-plugins/mytharchive/mytharchive-0.20.2_p14877 media-plugins/mythweather/mythweather-0.20.2_p14282 media-plugins/mythweather/mythweather-0.21_p16468 media-plugins/mythweather/mythweather-0.21_p17105 media-plugins/mythbrowser/mythbrowser-0.20.2_p14807 media-plugins/mythbrowser/mythbrowser-0.20.2_p14282 media-plugins/mythdvd/mythdvd-0.20.2_p14282 media-plugins/mythmovies/mythmovies-0.21_beta16366 media-plugins/mythmovies/mythmovies-0.21_p16468 media-plugins/mythcontrols/mythcontrols-0.20.2_p14282 media-plugins/mythmusic/mythmusic-0.20.2_p14282 media-plugins/mythmusic/mythmusic-0.21_p16468 media-plugins/mythmusic/mythmusic-0.21_p17015 media-plugins/mythphone/mythphone-0.20.2_p14282 media-plugins/mythphone/mythphone-0.21_p16468 media-plugins/mythphone/mythphone-0.21_p17105 media-plugins/mythvideo/mythvideo-0.20.2_p14684 media-plugins/mythvideo/mythvideo-0.20.2_p15087 media-plugins/mythgallery/mythgallery-0.20.2_p14282 media-plugins/mythflix/mythflix-0.20.2_p14282 media-plugins/mythflix/mythflix-0.20.2_p15488 media-plugins/mythgame/mythgame-0.20.2_p14282 media-plugins/mythnews/mythnews-0.20.2_p14282 media-plugins/mythnews/mythnews-0.21_p16468 media-plugins/mythnews/mythnews-0.21_p17105 media-tv/mythtv/mythtv-0.20.2_p14972 media-tv/mythtv/mythtv-0.20.2_p15634 www-apps/mythweb/mythweb-0.20.2_p14282 www-apps/mythweb/mythweb-0.20.2_p15488 www-apps/mythweb/mythweb-0.21_p16468 www-apps/mythweb/mythweb-0.21_p16809 x11-themes/mythtv-themes/mythtv-themes-0.20.2_p14301 We have to revbump every single ebuild* that might be affected by this before we even think about sending a GLSA. * or check the ebuild was created after the eclass was bumped.
Well, since that might take time. Why don't you just advise people to reinstall those packages after having: a) deleted their svn-src directories b) run emerge --sync ? Serves the same purpose and it is kind of faster (and this should be announced fairly soon IMHO). - ferdy
(In reply to comment #3) > Well, since that might take time. Why don't you just advise people to reinstall > those packages after having: If *we* don't know which packages, how should we expect users to know which "those" are to reinstall?
We do. Any package installed that uses git.eclass, subversion.eclass or mercurial.eclass. Those are quite easy to find with a one-liner script. Checking dates is pointless. The {svn,git,mercurial}-src directories are created the first time any package uses the eclass. - ferdy
(In reply to comment #5) > We do. Any package installed that uses git.eclass, subversion.eclass or > mercurial.eclass. Those are quite easy to find with a one-liner script. My research has generated a lot of false positives, because inheritance can be conditional, or the _src_unpack() might not be called. Once we have a list of all ebuilds that were vulnerable, filtering out those that were stable should be fairly easy. If you want to speed up the process, please help by generating the list as I already did for subversion.eclass. We should also need go back and look for ebuilds that do not exist anymore. Furthermore, all of these ebuilds have to be revbumped, because telling people to reemerge a package does not fit into the GLSA format, and everyone using tools like glsa-check will miss out the updates. As a step to increase overall security, and for those working on old distdirs, and not reading the GLSA description about deleting those directories: Shouldn't Portage bail out when it is asked to work on o+w directories? (Adding Zac and Marius)
(In reply to comment #6) > Shouldn't Portage bail out when it is asked to work on o+w directories? (Adding > Zac and Marius) If there's some way to extract the path of the directory from the package metadata (like SRC_URI) then we can do that. Without that, would we have check recursive contents of ${DISTDIR}? Doing anything recursive on ${DISTDIR} can be prohibitively expensive, particularly when it contains large source trees. It would have to be a one time adjustment and after that you'd just have to assume that the permissions are ok. An alternative would be to make the top level ${DISTDIR} o-rx so that attackers can never access the subdirectories.
(In reply to comment #6) > We should also need go back and look for ebuilds that do not exist anymore. > Furthermore, all of these ebuilds have to be revbumped, because telling people > to reemerge a package does not fit into the GLSA format, and everyone using > tools like glsa-check will miss out the updates. How do you revbump ebuilds that don't exist? > As a step to increase overall security, and for those working on old distdirs, > and not reading the GLSA description about deleting those directories: > Shouldn't Portage bail out when it is asked to work on o+w directories? (Adding > Zac and Marius) It'd be even easier to add that hack to the eclasses, however, that adds 0 security to the matter because people will do 'chmod o-rwx foo' and an attacker might have modified foo already. - ferdy
Is there anything that can be done to speed this up? - ferdy
Yes. The best case we need is a list of all vulnerable ebuilds that could still be installed on user's systems. That is ebuilds A) using the eclasses during a vulnerable timeframe B) have not been p.masked at that time and are not masked / removed now C) have not been superseded by newer ebuilds Then we need to: 1) Figure out which were stable / testing 2) Bump each of those ebuilds 3) Get those that were stable back to stable. Security is considering this to be a serious issue, but it only affects a minor set of packages. If you could assist in compiling such a list, that would be awesome.
(In reply to comment #10) > Security is considering this to be a serious issue, but it only affects a minor > set of packages. If you could assist in compiling such a list, that would be > awesome. Compiling such a list is unfeasible. I suggest just publicly disclosing this bug, keeping it secret is just useless. - ferdy
Well... - I agree with making public this issue. Indeed, finding insecure directories/files is one of the first things a local hacker will do if he is looking for root access. Restricting this information does not prevent a malicious user from exploiting the flaw. - I would tend to minimize the seriousness of that issue. A good unix administrator, running a multi-user box, should already apply basic security practices. Regularly looking for world-writable directories or files and evaluating their impact (in crontabs, in /etc/init.d, ...) is one of the basic security practices if you're concerned about security of your multi-user box. I'm sure there are many other ways to root a box if you already have a local unix account, some time, and some skill. Still, this should be fixed, for sure. About the fix, that plan sounds good to me: - The new eclass will die when finding a vulnerable directory, asking the user to manually rm -rf it (or whatever). - No ebuild will be revbumped. The GLSA will have no ebuild associated. I'm not sure this will work, but this should. - The GLSA will advise to delete the eclass cache, run emerge --sync, and manually check and fix the $DISTDIR/{svn,cvs,git}-src/ directories content (not only permissions), possibly simply deleting it.
CVE-2008-3797 has been reserved for this issue.
ferdy, any update on the patches?
I'm attaching ulm in light of the proposed bzr.eclass: Let's not reintroduce this issue again. Before moving the class into the tree, can we get a patch ready to bail out in case of improper permissions on DISTDIR?
As discussed with rbu on irc. I think something like the following should do the job: [ $(find "${DIR}" -maxdepth 0 -type d -perm -o+w) ] \ && die "${DIR} is world-writable, please remove it"
Created attachment 167417 [details, diff] Patch to check for world-writable directory Here is a patch for {git,mercurial,subversion}.eclass. I've tested it with subversion.eclass, but the logic is identical for all three eclasses. For bzr.eclass I'll commit a patched version directly.
Created attachment 167418 [details, diff] Patch to check for world-writable directory Take 2, adding some quotes.
That die message should point people to a page telling them to check their systems since they might have been compromised. That page can be the security advisory, for instance. Otherwise the check is not helping at all. - ferdy
(In reply to comment #19) > That die message should point people to a page telling them to check their > systems since they might have been compromised. That page can be the security > advisory, for instance. But that GLSA number or URL is not known yet, or could one be reserved? Or we could add the GLSA reference to the error message later.
Ideally, the patch would be committed the minute after the GLSA is released. - ferdy
We usually discuss eclass changes on -dev. Halcy0n and dberkholz, can you review the diff and leave a comment please?
I must admit that I did a stupid thing, namely I've accidentally committed a fixed bzr.eclass to the Emacs overlay (I wanted to commit another eclass but did a "svn ci" instead of "svn ci <filename>" in the directory). I've immediately (10 minutes later) asked robbat2 to remove the offending changeset r1171, however, two users already had it at this point.
I nulled out r1171 in the emacs overlay that had the private changes, but left the revisions existing as empty. It shouldn't break user systems, but the fact remains that two systems have copies of r1171. Overlays SVN/apache was turned off while I did the removal to prevent more. first user is 80.72.196.194, using a normal svn checkout. The second looks like an aggregator, so I think we still need to consider this exposed: 34.195.138 - - [12/Oct/2008:20:09:03 +0000] "GET http://overlays.gentoo.org/proj/emacs/changeset/1171 HTTP/1.1" 200 12323 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.3); http://spinn3r.com/robot) Gecko/20021130" I don't see why this is confidential anyway, when anybody reading the CVS changes for the eclasses can find where it was previously fixed. I'm also pretty sure zlin wasn't the first to find it, I had a discussion with somebody before about it, 6-9 months ago. Might have been ferringb, in person, not 100% sure.
Another two weeks have passed, without any visible progress. If there are no substantial objections, I'm going to commit bzr.eclass (_without_ the check for an existing world-writable dir) end of this week. AFAICS, this will not introduce any new problems, since the current version of bzr.eclass will not create the directory world-writable. And overlay users may already be affected by the issue, so this will not change.
Created attachment 169812 [details, diff] Patch to check for world-writable directory, including bzr.eclass (In reply to comment #25) > If there are no substantial objections, I'm going to commit bzr.eclass > (_without_ the check for an existing world-writable dir) end of this week. Done. An updated patch including bzr.eclass is attached.
Sorry, I missed that I was even CC'd on this. I don't see a problem with Ulrich's patch but this seems to me like something the package manager should enforce/check for. Just my 2 cents :) For now, whatever is the quickest and most efficient way to resolve this should be the way we go though.
As explained in comment #7, it's too expensive for the package manager to check recursive permissions on all subdirectories that might exist inside $DISTDIR.
I just want to bring to your attention that the inofficial "bzr-gentoo-overlay" again has a version of bzr.eclass that reintroduces the original issue: <http://bazaar.launchpad.net/~malept/bzr-gentoo-overlay/overlay-main/annotate>/head%3A/eclass/bzr-r9999.eclass> And it was already suggested that we replace the version in Portage by it. Which cannot be done unless this bug gets fixed.
Oops, broken URL. Here is the correct one: <http://bazaar.launchpad.net/~malept/bzr-gentoo-overlay/overlay-main/annotate/head%3A/eclass/bzr-r9999.eclass>
Looks like there is no progress since 8 years. I suggest to make this bug public and close the issue as obsolete. git.eclass is gone since a long time, as well as all the ebuilds listed in comment #2. The other three eclasses have been fixed years ago.
(In reply to Ulrich Müller from comment #31) > Looks like there is no progress since 8 years. > > I suggest to make this bug public and close the issue as obsolete. > git.eclass is gone since a long time, as well as all the ebuilds listed in > comment #2. The other three eclasses have been fixed years ago. Concur. Any other concerns from @security?
