A security issue in Transmission has been announced on January 11: http://openwall.com/lists/oss-security/2018/01/12/1 The message above contains a link to a patch to fix the issue. Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO
QA Contact: (none) => securityComponent: RPM Packages => Security
CVE-2018-5702 assigned: http://openwall.com/lists/oss-security/2018/01/15/1
Summary: transmission new security issue can lead to remote code execution => transmission new security issue can lead to remote code execution (CVE-2018-5702)
Debian has issued an advisory for this on January 14: https://www.debian.org/security/2018/dsa-4087
Fedora has issued an advisory for this on January 17: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/7E4DGDKW672SG6QYQ7KN4HOPXJIR52K7/
Fedora issued another advisory today (January 30) with fixes to the CVE patch: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/FDCZPHXGNXFC7FZIR3URL2WFESMAZVJ6/
Status comment: (none) => Patches available from Fedora
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
Advisory: ======================== 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). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702 https://www.debian.org/security/2018/dsa-4087 ======================== Updated packages in core/updates_testing: ======================== transmission-common-2.92-3.1.mga6 transmission-cli-2.92-3.1.mga6 transmission-gtk3-2.92-3.1.mga6 transmission-qt5-2.92-3.1.mga6 transmission-daemon-2.92-3.1.mga6 from transmission-2.92-3.1.mga6.src.rpm
Whiteboard: MGA6TOO => (none)Assignee: rverschelde => qa-bugsVersion: Cauldron => 6
Advisory uploaded.
Keywords: (none) => advisory
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
$ 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
$ uname -a Linux localhost 4.14.25-desktop-1.mga6 #1 SMP Fri Mar 9 21:01:49 UTC 2018 i686 i686 i686 GNU/Linux 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.
$ 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.
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
Shouldn't need feedback, this bug is already marked as dependent on the Qt5 update.
Whiteboard: feedback => (none)
Poking M6/64 BEFORE update I installed all the pkgs: transmission-gtk3-2.92-3.mga6 transmission-qt5-2.92-3.mga6 transmission-common-2.92-3.mga6 transmission-cli-2.92-3.mga6 transmission-daemon-2.92-3.mga6 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: 127.0.0.1 [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.
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. http://www.mirrorservice.org/sites/mageia.org/pub/mageia/iso/6/torrents/
@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.
@Claire: thanks for the Web pointer; and the URL for our list of ISOs. I used: http://www.mirrorservice.org/sites/mageia.org/pub/mageia/iso/6/torrents/Mageia-6-x86_64-DVD.torrent Background 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: https://help.ubuntu.com/community/TransmissionHowTo http://www.junauza.com/2009/01/how-to-use-bittorrent-in-linux.html https://helpdeskgeek.com/how-to/using-the-transmission-web-interface/ Not forgetting the 2 GUIs and their F1 Help -> hhttps://transmissionbt.com/help/gtk/2.9x/ 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'. 127.0.0.1 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... -------------------------------- UPDATE to: transmission-cli-2.92-3.1.mga6 transmission-common-2.92-3.1.mga6 transmission-daemon-2.92-3.1.mga6 transmission-gtk3-2.92-3.1.mga6 transmission-qt5-2.92-3.1.mga6 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.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA6-64-OKCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0230.html
Status: NEW => RESOLVEDResolution: (none) => FIXED