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
dev-python/twisted calls python -c in update_plugin_cache in pkg_postinst
net-mail/fetchmail calls python -c in pkg_postinst, should use
sys-apps/portage calls python -c in compile_all_python_bytecodes from
app-admin/sabayon calls python_mod_exists from pkg_setup
dev-python/pythong calls python_mod_exists/python_tkinter_exists from
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
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
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-18.104.22.168 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]
22.214.171.124 patch that applies on top of 126.96.36.199
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"`
* 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-188.8.131.52.ebuild to make work for 184.108.40.206
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug:
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-220.127.116.11.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-18.104.22.168
Sun Oct 5 16:54:34 2008 >>> sys-apps/portage-22.214.171.124
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-126.96.36.199
Mon Oct 6 18:59:57 2008 >>> sys-apps/portage-188.8.131.52
looks good on ppc, too
I think everyone's accounted for. Shall I go ahead and add portage-184.108.40.206 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 220.127.116.11 and 2.2_rc12.
Thanks, closing then.