solar pointed out in bug 224925 that python -c will prepend . to sys.path, loading imports from the CWD. If an attacker can place a crafted python module (such as tkinter.py) in a world-writable directory, and entice the root user to run 'emerge' from that directory, he would gain root privileges if emerge calls ebuild functions that do not have their CWD sanitized (which is the case for all pkg_ functions). The following list of ebuilds is vulerable to these attacks: app-text/txt2tags calls python -c in pkg_setup, should use python_mod_exists dev-python/twisted calls python -c in update_plugin_cache in pkg_postinst and pkg_postrm net-mail/fetchmail calls python -c in pkg_postinst, should use python_mod_exists sys-apps/portage calls python -c in compile_all_python_bytecodes from pkg_postinst app-admin/sabayon calls python_mod_exists from pkg_setup dev-python/pythong calls python_mod_exists/python_tkinter_exists from pkg_setup app-editors/leo calls python_tkinter_exists from pkg_setup games-board/pysol calls python_tkinter_exists from pkg_setup media-gfx/skencil calls python_tkinter_exists from pkg_setup media-sound/lilycomp calls python_tkinter_exists from pkg_setup net-im/msnlib calls python_tkinter_exists from pkg_setup sci-misc/gato calls python_tkinter_exists from pkg_setup sci-visualization/mayavi calls python_tkinter_exists from pkg_setup twisted.eclass calls python -c in update_plugin_cache from twisted_pkg_postrm and twisted_pkg_postinst affects: dev-python/twisted-conch dev-python/twisted-flow dev-python/twisted-lore dev-python/twisted-mail dev-python/twisted-names dev-python/twisted-news dev-python/twisted-pair dev-python/twisted-runner dev-python/twisted-web dev-python/twisted-words dev-python/twisted-xish
zmedico agreed that this issue is best fixed in Portage itself, as that would also secure ebuilds in overlays, and future mistakes in trusting 'python -c'. Portage 2.2_rc10 tries to sanitize the CWD (cd $PORTAGE_BUILDDIR) before calling pkg_ functions in ebuilds, but fails when the directory does not exist (such as in the pkg_setup() function). Zac, we need to make sure the cd call has a target that is guaranteed to exist, and emerge dies if it fails. Steps to reproduce: rbu@peanut /tmp $ cat _tkinter.py open("/tmp/owned", 'w').write('yes') rbu@peanut /tmp $ ls -la _tkinter.py owned ls: cannot access owned: No such file or directory -rw-r--r-- 1 rbu rbu 37 2008-10-04 18:29 _tkinter.py In a root shell, run: peanut tmp # USE=tk emerge app-text/txt2tags And then we see: rbu@peanut /tmp $ ls -la _tkinter.py owned -rw-r--r-- 1 root root 3 2008-10-04 18:29 owned -rw-r--r-- 1 rbu rbu 38 2008-10-04 18:29 _tkinter.py
General TODOs for this issue: 1) Prepare a patch to ebuild.sh 2) Prepare a portage-2.1.4.5 release (non-public), that we then test with arch security liaisons on this bug. 3) Push out a GLSA and the stable Portage release. 4) Contact other package manager maintainers about their (~arch) PMs 5) Include CWD preconditions in EAPI
Created attachment 167252 [details, diff] 2.1.4.5 patch that applies on top of 2.1.4.4 The first and last hunks (in ebuild.sh and portage.py) are for this bug: Fixes for Bug #239560: * When ensuring sane $PWD in ebuild.sh, die if the `cd "$PORTAGE_BUILDDIR"` call fails. * In portage.py, create $PORTAGE_BUILDDIR for the "fetch" phase too since it might be necessary to call pkg_nofetch. The patch also includes some patches for a few other bugs that should also get fixed since we're doing a bump: Bug #239471 - Handle InvalidDependString from portdbapi.getfetchlist() inside search.output(). (trunk r11602) Bug #239006 - In FakeVartree._aux_get_wrapper(), fall back to vdb metadata if the live ebuild's EAPI is unsupported. (trunk r11600) Bug #222091 - Filter out any instances of the \1 character from variable values since this character multiplies each time that the environment is saved (strange bash behavior). This can eventually result in mysterious 'Argument list too long' errors from programs that have huge strings of \1 characters in their environment. (trunk r11485)
Created attachment 167255 [details, diff] patch portage-2.1.4.4.ebuild to make work for 2.1.4.5
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug: =sys-apps/portage-2.1.4.5 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" CC'ing current Liaisons: alpha : yoswink, armin76 amd64 : keytoaster, tester hppa : jer ppc : dertobi123 ppc64 : corsair sparc : fmccor x86 : maekke, armin76
Sparc looks good. Patch installs cleanly to ebuild, ebuild cleanly installs the portage-2.1.4.5.patch, and it builds and installs as expected. Resulting portage can install things, including itself. ========================== Sun Oct 5 16:49:20 2008 >>> sys-apps/portage-2.1.4.5 Sun Oct 5 16:54:34 2008 >>> sys-apps/portage-2.1.4.5
HPPA is OK.
looks good on ppc64
Looks okay on alpha/arm/ia64/sh/x86
Okay on amd64. ============== Mon Oct 6 18:59:22 2008 >>> sys-apps/portage-2.1.4.5 Mon Oct 6 18:59:57 2008 >>> sys-apps/portage-2.1.4.5
looks good on ppc, too
I think everyone's accounted for. Shall I go ahead and add portage-2.1.4.5 to the tree, directly with stable keywords?
please give us a day to finish glsa drafting and review
public, this is GLSA-200810-02
Now this released in both 2.1.4.5 and 2.2_rc12.
Thanks, closing then.
