Package: python
Version: 2.4.4-1
Severity: grave
Tags: security
Justification: user security hole

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not really sure what severity this should be. Dumping files all over
the filesystem and never clearing them up afterwords is not specifically
proscribed by Policy, but it's not good thing to do...

Basically, python creates these .pyo and .pyc packages whenever it reads
a .py file in a writeable directory. The problem is that when code is
run as root, these files get created but there is no mechanism to remove
them when they are no longer needed. As a result, obsolete code is left
all over the place, opening the user up to subtle bugs and possibly even
security holes; consider this sequence of events:

 1. user installs foo which recommends python-bar for additional
    functionality
 2. user runs foo as root; .pyc and .pyo files are created all over the
    place
 3. user removes python-bar
 4. python-bar gets a security update. Because python-bar is no longer
    installed, according to dpkg, it is never upgraded
 5. foo happily continues to 'import bar' and python allows it to import
    the insecure version of the module via the .pyc/.pyo files that were
        never removed

On my desktop system, which originally ran woody and now runs etch with
some packages pulled from unstable, the following script revealed a lot
of these files:

$ locate *.pyc *.pyo | while read line; do echo "${line%[co]}"; done |
 sort -u | while read line; do test -f "$line" || echo "$line"; done | wc -l
49

Unfortunately, due to the circumstances in which these files are
created, I don't see of any way to automatically scan the archive to
find all such files; however, the script above makes it easy to find and
remove them by hand.

I think the easiest way to mitigate the impact of this bug would be to
patch each python interpreter that we ship to only use a .pyc/.pyo file
if the corresponding .py file already exists. (Does anyone know how many
packages ship their own copy of the interpreter rather than linking
against libpython dynamically?)

- -- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages python depends on:
ii  python-minimal                2.4.4-1    A minimal subset of the Python lan
ii  python2.4                     2.4.4-1    An interactive high-level object-o

python recommends no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFTbMtshl/216gEHgRAibPAJ4l6kmLKSBjRl4oNawCi2Z3wPDDwACgu7iZ
BnLfySp34HnYFx2m8j3YOGg=
=/5Ey
-----END PGP SIGNATURE-----


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to