Bugzilla Bug 239560

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 an attachment (id=167252) [details]
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 an attachment (id=167255) [details]
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.