touch-packages team mailing list archive

[Launchpad Bug Tracker <1507480@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package apport - 2.14.1-0ubuntu3.18

---------------
apport (2.14.1-0ubuntu3.18) trusty-security; urgency=medium

  * test_backend_apt_dpkg.py: Reset internal apt caches between tests. Avoids
    random test failures due to leaking paths from previous test cases.
  * SECURITY FIX: When determining the path of a Python module for a program
    like "python -m module_name", avoid actually importing and running the
    module; this could lead to local root privilege escalation. Thanks to
    Gabriel Campana for discovering this and the fix!
    (CVE-2015-1341, LP: #1507480)

 -- Martin Pitt <martin.pitt@xxxxxxxxxx>  Thu, 22 Oct 2015 15:15:37
+0200

** Changed in: apport (Ubuntu Trusty)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1507480

Title:
  Privilege escalation through Python module imports

Status in Apport:
  In Progress
Status in apport package in Ubuntu:
  In Progress
Status in apport source package in Precise:
  Fix Released
Status in apport source package in Trusty:
  Fix Released
Status in apport source package in Vivid:
  Fix Released
Status in apport source package in Wily:
  Fix Released
Status in apport source package in Xenial:
  In Progress

Bug description:
  Gabriel Campana <gabriel@xxxxxxxxxxxxxxxxx> reported a security
  vulnerability in Apport:

  ummary
  =======

  A privilege escalation was discovered in apport.

  
  Details
  =======

  The command line of the process triggering the coredump is checked to
  determine if it's a script. If the interpreter is Python and the first
  argument is ``-m``, the method ``_python_module_path`` is called to find
  the path of the culprit module
  (``/usr/lib/python3/dist-packages/apport/report.py``)::

      @classmethod
      def _python_module_path(klass, module):
          '''Determine path of given Python module'''

          module = module.replace('/', '.')

          try:
              m = __import__(module)
              m
          except:
              return None

          [...]

  Any Python module in ``sys.path`` can be imported because the variable
  ``module`` is under control of the attacker. It should be noted that
  ``_python_module_path`` is called with euid=0, and apport relies on the
  process name to determine if the process is an interpreter. A crash of
  Python isn't required to reach this function: any process name starting
  with ``python`` and producing a core dump is enough. As an example, the
  following bash script triggers the bug::

         #!/bin/bash

          cat <<EOF > python.c
          int main(void) { *(int *)0 = 0; return 0; }
          EOF
          gcc -o python python.c
          ./python -m venv.__main__

  and results in the creation of a "lightweight virtual Python
  environment" in the root directory::

          $ ./lol.sh
          ./lol.sh: line 8:  7665 Segmentation fault      (core dumped)
          $ ls -l / | head -4
          total 100
          drw-rw----   5 root root  4096 Sep 29 16:09 7665
          drwxr-xr-x   2 root root  4096 Sep 29 05:41 bin
          drwxr-xr-x   3 root root  4096 Sep 29 06:20 boot

  
  Criticity
  =========

  Importing an arbitrary module is a security issue because a few standard
  modules rely on files in the home directory associated to the uid of the
  dumped process. A fully working exploit has been written (targetting
  Python2 and Python3), giving an instant root shell to the attacker.
  While the exploitation is straightforward for Python2, a bit more work
  was required to find a suitable module for Python3.

  The vulnerability seems to be limited to Ubuntu Dekstop because apport
  is disabled on Ubuntu Server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1507480/+subscriptions