Package: tucan
Version: 0.3.9-1
Severity: grave
Tags: security
Justification: user security hole
Tucan comes with plugins to handle downloads from the various
download sites it supports. These plugins are basically python modules
which run with the same permissions as the user running tucan. The
tucan package comes with a set of such plugins in
/usr/share/default_plugins/, but it downloads updates of these plugins
via http/https and places them in ~/.tucan/plugins/. This means that
after an update, debian-packaged code is effectively replaced by code
directly from the upstream repository. This in itself is problematic,
but because the update mechanism is implemented in an insecure
fashion, a remote attacker could use it introduce a malicious plugin
which executes arbitrary code with the permissions of the user running
tucan.
The plugins tucan downloads are unsigned, so a remote attacker could
introduce a plugin containing malicious code either by compromising
the remote sites where the plugins are stored, or by means of a
man-in-the-middle attack on the http/https connection from tucan to
the site holding the updates (tucan doesn't seem to check the server
certificate on SSL connections). Tools for automating this kind of
exploit exist, e.g. https://code.google.com/p/ippon-mitm/
The best way to address this problem is probably to disable the update
mechanism entirely in the debian package, and distribute updated
plugin files via apt. (Upstream might want to look into signing their updates,
and possibly making changes to the program's design so that the plugins
run in some kind of sandbox rather than with full user permissions.)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
