Bug 22379 - transmission new security issue can lead to remote code execution (CVE-2018-5702)
Summary: transmission new security issue can lead to remote code execution (CVE-2018-5...
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on: 22657
  Show dependency treegraph
Reported: 2018-01-12 15:24 CET by David Walser
Modified: 2018-05-12 08:29 CEST (History)
4 users (show)

See Also:
Source RPM: transmission-2.92-5.mga7.src.rpm
Status comment: Patches available from Fedora


Description David Walser 2018-01-12 15:24:48 CET
A security issue in Transmission has been announced on January 11:

The message above contains a link to a patch to fix the issue.

Mageia 5 and Mageia 6 are also affected.
David Walser 2018-01-12 15:24:57 CET

Whiteboard: (none) => MGA6TOO

David Walser 2018-01-12 15:25:26 CET

QA Contact: (none) => security
Component: RPM Packages => Security

Comment 1 David Walser 2018-01-16 02:10:42 CET
CVE-2018-5702 assigned:

Summary: transmission new security issue can lead to remote code execution => transmission new security issue can lead to remote code execution (CVE-2018-5702)

Comment 2 David Walser 2018-01-16 12:07:14 CET
Debian has issued an advisory for this on January 14:
Comment 3 David Walser 2018-01-19 16:11:12 CET
Fedora has issued an advisory for this on January 17:
Comment 4 David Walser 2018-01-31 03:40:31 CET
Fedora issued another advisory today (January 30) with fixes to the CVE patch:
David Walser 2018-02-02 18:29:18 CET

Status comment: (none) => Patches available from Fedora

Comment 5 David GEIGER 2018-02-26 06:19:21 CET
package from Cauldron was fixed updating to the latest upstream 2.93 release.

Done also for mga6 with an upstream patch.

CC: (none) => geiger.david68210

Comment 6 David Walser 2018-02-26 12:20:19 CET

Updated transmission packages fix security vulnerability:

Tavis Ormandy discovered a vulnerability in the Transmission BitTorrent client;
insecure RPC handling between the Transmission daemon and the client
interface(s) may result in the execution of arbitrary code if a user visits a
malicious website while Transmission is running (CVE-2018-5702).


Updated packages in core/updates_testing:

from transmission-2.92-3.1.mga6.src.rpm

Assignee: rverschelde => qa-bugs
Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

Comment 7 claire robinson 2018-02-28 17:11:28 CET
Advisory uploaded.

Keywords: (none) => advisory

Comment 8 claire robinson 2018-03-01 23:55:09 CET
This also appears to require Qt 5.9. Adding the depends.

To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Updates Testing")
  libqt5core5                    5.9.4        1.mga6        i586    
  qtbase5-common                 5.9.4        1.mga6        i586    
  transmission-cli               2.92         3.1.mga6      i586    
  transmission-common            2.92         3.1.mga6      noarch  
  transmission-daemon            2.92         3.1.mga6      i586    
  transmission-gtk3              2.92         3.1.mga6      i586    
  transmission-qt5               2.92         3.1.mga6      i586    
1MB of additional disk space will be used.
5MB of packages will be retrieved.
Proceed with the installation of the 7 packages? (Y/n) n

# urpmq --requires transmission-qt5 | grep Qt_5.9
--requires behaviour changed, use --requires-recursive to get the old behaviour
transmission-qt5: libQt5Core.so.5(Qt_5.9)

Depends on: (none) => 22657

Comment 9 Brian Rockwell 2018-03-14 03:20:32 CET
$ uname -a
Linux localhost 4.14.20-desktop-1.mga6 #1 SMP Sun Feb 18 01:22:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I installed Qt_5.9, but don't think tranmission-cli was looking for it.

installed tranmission-cli 2.92-3.1 and common files.

$ transmission-cli -v
transmission-cli 2.92 (14714)

$ transmission-cli KaOS-2018.03-x86_64.iso.4ad8bb065bde5d4e.torrent

It is in the process of downloading and interfacing with the torrent as designed.  This particule instance is XFCE so it doesn't have gtk3 or qt5 versions of transmission.  I'll have to look at Plasma and see.

however - these two pieces are working as designed.

CC: (none) => brtians1

Comment 10 Brian Rockwell 2018-03-14 15:47:40 CET
$ uname -a 
Linux localhost 4.14.25-desktop-1.mga6 #1 SMP Fri Mar 9 21:01:49 UTC 2018 i686 i686 i686

This machine does have qt5.9 and plasma 5.12

The following 5 packages are going to be installed:

- transmission-cli-2.92-3.1.mga6.i586
- transmission-common-2.92-3.1.mga6.noarch
- transmission-daemon-2.92-3.1.mga6.i586
- transmission-gtk3-2.92-3.1.mga6.i586
- transmission-qt5-2.92-3.1.mga6.i586

9.8MB of additional disk space will be used.

2.4MB of packages will be retrieved.

Is it ok to continue?

QTTransmission – working as designed
Transmission – the gtk client works as designed.

Both are able to seed and process files.
Comment 11 Brian Rockwell 2018-03-14 16:22:36 CET
$ uname -a
Linux localhost 4.14.20-desktop-1.mga6 #1 SMP Sun Feb 18 01:22:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Installed only gtk3 instance

Not QT 5.9 installed older plasma version

Transmission gtk is working as designed.
Comment 12 Brian Rockwell 2018-03-14 16:30:50 CET
so went back and installed the transmission qt5 version

Mar 14 10:27:38 localhost [RPM][2975]: install qtbase5-common-5.9.4-1.1.mga6.x86_64: success
Mar 14 10:27:38 localhost [RPM][2975]: install lib64qt5core5-5.9.4-1.1.mga6.x86_64: success
Mar 14 10:27:38 localhost [RPM][2975]: install transmission-qt5-2.92-3.1.mga6.x86_64: success

yes it does pick up qt5.9

using the qt5 version it will not display the screen (this is old plasma)

gtk works.

Whiteboard: (none) => feedback

Comment 13 David Walser 2018-03-15 21:40:27 CET
Shouldn't need feedback, this bug is already marked as dependent on the Qt5 update.

Whiteboard: feedback => (none)

Comment 14 Lewis Smith 2018-03-23 11:39:15 CET
Poking M6/64

BEFORE update I installed all the pkgs:
I already have the Qt5 5.9.3 update.

Trying this with Brian's example URL from c9, I am  hampered by ignorance of how to drive BitTorrents. Using LXDE:

From the destination directory:
 $ transmission-cli KaOS-2018.03-x86_64.iso.4ad8bb065bde5d4e.torrent
transmission-cli 2.92 (14714)
[2018-03-23 10:25:52.338] Transmission 2.92 (14714) started
[2018-03-23 10:25:52.340] RPC Server: Adding address to whitelist:
[2018-03-23 10:25:52.341] UDP: Failed to set receive buffer: requested 4194304, got 425984
[2018-03-23 10:25:52.341] UDP: Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf
[2018-03-23 10:25:52.341] UDP: Failed to set send buffer: requested 1048576, got 425984
[2018-03-23 10:25:52.341] UDP: Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf
[2018-03-23 10:25:52.341] DHT: Generating new id
ERROR: Unrecognized torrent "KaOS-2018.03-x86_64.iso.4ad8bb065bde5d4e.torrent".
 * If you're trying to create a torrent, use transmission-create.
 * If you're trying to see a torrent's info, use transmission-show.
[2018-03-23 10:25:52.388] DHT: Not saving nodes, DHT not ready
[2018-03-23 10:25:52.388] Port Forwarding: Stopped
Starting "Transmission" from the menu (= $ transmission-gtk) launched a functional GUI, but of the URL it said 'Unrecognisable URL' which it 'does not know how to use'.
 $ transmission-gtk
(transmission-gtk:10344): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
(transmission-gtk:10344): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

Trying similarly "Qtransmission Bittorrent Client" (= $ transmission-qt) also launched a good but different GUI which complained of the URL 'Invalid or corrupt torrent file'.
 $ transmission-qt
threw no errors.

@Brian : Can you possibly furnish a Torrent URL which should start? Where does the daemon come into this?
I will try the update once I get going with the current packages.
Comment 15 claire robinson 2018-03-23 16:13:44 CET
It's a daemon with multiple frontends. One of which is a web front end accessible in a browser, which is what is vulnerable here. IIRC it needs to be enabled first in the options.

For a torrent to use eg.
Comment 16 Brian Rockwell 2018-03-24 22:37:14 CET
@Lewis - Yes - just use the link above for the torrent.

@Lewis - I just downloaded the torrent file to a folder and then ran it in using the transmission-cli in one instance and the gui in another.

I used kaos as the download and synching was a bit smaller, plus somethign interesting.
Comment 17 Lewis Smith 2018-03-26 14:46:37 CEST
@Claire: thanks for the Web pointer; and the URL for our list of ISOs. I used:

There is no central repository of documentation at the Transmission web site: https://transmissionbt.com/ . Links from there are scattered, and sometimes go in circles. These are the best I found:
Not forgetting the 2 GUIs and their F1 Help ->

All the Qt->KDE stack updated, under Plasma.

Our transmission-daemon is *not* a regular Linux service, but started as a normal program (which does not show in the MCC services list):
 $ transmission-daemon
 $ ps -ax | grep transmission
 23792 ?        Ssl    0:00 transmission-daemon
which has a man page and lots of options (except stop; kill the PID?).

To enable Web access (which requires the daemon if nothing else is running, but not apparently if one of the GUIs is), from either GUI Edit-Preferences-Remote, enable 'remote access'. is pre-defined. To see it in a browser, either click 'Open web client', or -> http://localhost:9091

I had problems mixing the daemon, web interface, and 2 GUIs. Using (daemon started) just the web interface worked fine for managing a download, but I could not open it with a GUI; nor having killed it from the web interface, could I re-start it from a GUI. After killing the *daemon*, the GUIs worked for new downloads. And the web interface (no daemon) then shows in parallel its progress, and can control it.

Killed the download & all transmission programs before...

Started the daemon, http://localhost:9091 added the URL for 'Open torrent', away it went. Paused & resumed it. The 'Inspector' button works fine. Could not see the same torrent from the GUI open dialogues. Paused the torrent from the web, killed the window & the daemon, then could see but not open & re-start the same download from the GUIs.
 Abandoning those, clearing out the paused download, killing the daemon, I then started a new download for the Qt GUI. Worked fine, pause, resume. And it *was* visible in parallel from the web interface, *without* the daemon running. Paused from the Qt GUI, closed it. This cause a failure connection from the web page, which requires a response after... Started the Gtk GUI, which automatically found the paused download, which I was able to resume. The unblocked web interface then worked in parallel (no daemon).

The old question of knowing how to drive it. This all looks good! OKing & validating at last.

CC: (none) => lewyssmith, sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA6-64-OK

Comment 18 Mageia Robot 2018-05-12 08:29:06 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.