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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
