Package: emacs22-common Version: 22.2+2-3 Severity: important Tags: security patch fixed-upstream
The following mail was sent to the emacs-devel mailing list shortly after the release of Emacs 22.3:
--- Begin Message ---Romain Francoise has found a security risk in a feature of GNU Emacs related to how Emacs interacts with Python. Emacs version 22.3, which was just released, contains a fix. A patch for earlier version of Emacs is described below. The vulnerability may allow an attacker to run malicious code if the user runs the Emacs command `run-python' while the current directory is world-writable, or if the user toggles `eldoc-mode' and visits a Python source file in a world-writable directory. Description of the vulnerability: The Emacs command `run-python' launches an interactive Python interpreter. After the Python process starts up, Emacs automatically sends it the line import emacs which normally imports a script named emacs.py which is distributed with Emacs. This script, which is typically located in a write-protected installation directory with other Emacs program files, defines various functions to help the Python process communicate with Emacs. The vulnerability arises because Python, by default, prepends '' to the module search path, so modules are looked for in the current directory. If the current directory is world-writable, an attacker may insert malicious code by adding a fake Python module named emacs.py into that directory. Furthermore, emacs.py imports other non-built-in Python modules, such as `inspect'. The same vulnerability exists for these import statements. By default, merely visiting and editing a *.py source file does not launch a Python subprocess; you either have to call `M-x run-python', or enable Emacs code that calls `run-python' automatically, such as `eldoc-mode'. The Python developers, in a private communication, have stated that they do not regard this module-importing behavior as a security problem for Python per se, because running a python script in a world-writable directory is itself a security hazard. In the Emacs context, however, it's much less obvious that it's unsafe to call `run-python' while the current directory is world-writable; therefore, the problem discussed here can be regarded as a security risk. The following patch, against the Emacs 22.2 source tree, removes '' from sys.path in the command-line arguments for invoking the Python process. (Because `sys' is a "built-in module", an attacker cannot insert malicious code by adding sys.py to the current directory.) *** emacs/lisp/progmodes/python.el 8 May 2008 03:42:10 -0000 1.89 --- emacs/lisp/progmodes/python.el 24 Aug 2008 19:47:09 -0000 1.90 *************** *** 1547,1553 **** ;; invoked. Would support multiple processes better. (when (or new (not (comint-check-proc python-buffer))) (with-current-buffer ! (let* ((cmdlist (append (python-args-to-list cmd) '("-i"))) (path (getenv "PYTHONPATH")) (process-environment ; to import emacs.py (cons (concat "PYTHONPATH=" --- 1547,1555 ---- ;; invoked. Would support multiple processes better. (when (or new (not (comint-check-proc python-buffer))) (with-current-buffer ! (let* ((cmdlist ! (append (python-args-to-list cmd) ! '("-i" "-c" "import sys; sys.path.remove('')"))) (path (getenv "PYTHONPATH")) (process-environment ; to import emacs.py (cons (concat "PYTHONPATH="
--- End Message ---
If you fix this vulnerability please also include the CVE id in your changelog entry. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26.5-libata Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs22-common depends on: ii dpkg 1.14.22 Debian package management system ii emacsen-common 1.4.17 Common facilities for all emacsen emacs22-common recommends no packages. Versions of packages emacs22-common suggests: pn emacs22-common-non-dfsg <none> (no description available) ii emacs22-el 22.2+2-3 GNU Emacs LISP (.el) files -- no debconf information
_______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
