Azureus always listens on local port without authentication

Bug #222630 reported by Gilles Peskine on 2008-04-26
260
Affects Status Importance Assigned to Milestone
Azureus
Unknown
Unknown
azureus (Debian)
Fix Released
Unknown
azureus (Ubuntu)
Medium
Stefano Maioli

Bug Description

Binary package hint: azureus

Summary: Azureus listens on localhost:6880. A local attacker can cause a running Azureus to download torrents, spam dialog boxes, and perhaps more.

As user alice, start Azureus. If this is Alice's first time using Azureus, accept the defaults from the configuration wizard.

================================================================
alice$ rm -rf ~/.[Aa]zureus
alice$ azureus
changeLocale: *Default Language* != English (United States). Searching without country..
changeLocale: Searching for language English in *any* country..
changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)'
================================================================

Now Azureus is accepting connections from localhost on port 6880. Another user on the same machine can feed data to Alice's instance.

================================================================
eve$ azureus /DATA/misc/torrents/ubuntu-8.04-desktop-i386.iso.torrent
StartSocket: passing startup args to already-running Azureus java process listening on [127.0.0.1: 6880]
================================================================

A dialog box appears on Alice's desktop, asking her where to download the torrent. If Alice had selected a default download directory under "Options/Files/Default Directory", her instance would start downloading the torrent without Alice taking any action.

SECURITY PROBLEM: If the torrent points to illegal files, Alice will have trouble proving she didn't initiate the download.

Eve can also spam Alice with error pop-ups, and possibly trigger other behavior in Alice's instance:
================================================================
eve$ azureus -Dqwertyuiop
StartSocket: passing startup args to already-running Azureus java process listening on [127.0.0.1: 6880]
================================================================
Here Alice gets an error message "Failed to access torrent file 'Dqwertyuiop'. Ensure sufficient temporary file space available (check browser cache usage).", then again with the files 'qwertyuiop', 'wertyuiop', '-e' and 'rtyuiop'. Alice has to close one dialog box per message. It looks like Azureus is trying to interprete the argument both as a file name and as options. This is really a separate bug, but it may make for a worse exploit with some bad options.

I notice that Azureus also listens locally on port 45100 (47986 is the expected peer-listening port). I don't know if this one is a problem.
================================================================
alice$ lsof -p9925 |grep LISTEN
java 9925 gilles 3u IPv6 26956 TCP localhost.localdomain:6880 (LISTEN)
java 9925 gilles 11u IPv6 26961 TCP *:47986 (LISTEN)
java 9925 gilles 24u IPv6 26984 TCP localhost.localdomain:45100 (LISTEN)
================================================================

This bug was observed with Azureus 2.4.0.2-0ubuntu2 on an Ubuntu dapper/amd64 system, but looks pervasive. I tried downloading Azureus 3.0.5.2 (linux/i386 binary) from sourceforge.net. With default settings, it still accepts torrents from other local users, displaying a pop-up window that disappears after a few seconds.

Related branches

John Dong (jdong) wrote :

Thanks for your bug report,

If I understand correctly from the bug report, Azureus is using a local TCP port as a form of inter-process communication which allows all local users capable of connecting to the port to control each others' Azureus instances. Is this correct?

This is also an upstream bug, and probably a design flaw more than a security vulnerability. If it's not too much trouble, would you mind filing this bug upstream too?

Changed in azureus:
importance: Undecided → Medium
status: New → Confirmed
Stefano Maioli (smaioli) wrote :

I agree this is a very annoying "feature". It also prevents multiple instances to run on the same machine.

I reported upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=2062854&group_id=84122&atid=575154 ,
but I don't think there's much we can do in Ubuntu.

Stefano Maioli (smaioli) on 2008-08-23
Changed in azureus:
assignee: nobody → smaioli
Stefano Maioli (smaioli) on 2008-08-24
Changed in azureus:
status: Confirmed → In Progress
Changed in azureus:
status: Unknown → Confirmed
Stefano Maioli (smaioli) on 2008-09-17
Changed in azureus:
status: In Progress → Fix Committed
Stefano Maioli (smaioli) wrote :

Fixed in: azureus (3.1.1.0-3ubuntu2)
--------

  * Bug fix upload (LP: 261879).
  * Added gconf schema for magnet URLs (LP: 50975).
  * Removed useless files from the produced .jar in build.xml (LP: 259603).
  * Automatic interface type selection based on whether vuze
    is installed or not.
    - Added symbolic link /usr/bin/vuze.
    - In debian/bin/azureus test for the presence of vuze.
  * Multi-user patch (see README.multiuser) (LP: 222630):
    - Allow one instance per user as opposed to one instance per machine.
    - A user can no longer control another user's instance.

Changed in azureus:
status: Fix Committed → Fix Released
Changed in azureus (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.