openSUSE has issued an advisory on September 27: https://lists.opensuse.org/opensuse-updates/2016-09/msg00101.html We already fixed CVE-2014-0791, but their bug also mentions CVE-2013-4119, and has links to upstream commits to fix that and CVE-2013-4118. Part of the CVE-2013-4119 patch applies to our Mageia 5 sources too, so I imagine that's also relevant for us. Both of these fixes should already be in the version in Cauldron.
Patch for CVE-2013-4118 applies after a rediff: https://github.com/FreeRDP/FreeRDP/commit/7d58aac24fe20ffaad7bd9b40c9ddf457c1b06e7 But patch for CVE-2013-4119 does not applied properly, there is just one line that can be applied, so for me this one is not necessary: https://github.com/FreeRDP/FreeRDP/commit/0773bb9303d24473fe1185d85a424dfe159aff53
Indeed it is only one line, the first instance of "transport->credssp = NULL;" in transport_connect_nla in transport.c, but it could be that that line should still be added.
It doesn't build with this rebase patche: http://pkgsubmit.mageia.org/uploads/failure/5/core/updates_testing/20160929150922.daviddavid.duvel.17546/log/freerdp-1.0.2-5.1.mga5/build.0.20160929150944.log
s/rebase patche/rebased patch/
FreeRDP 1.0.2 uses "false" instead of "FALSE"
Indeed! pfff I'm really stupid :) Thanks David!
Done for mga5!
Thanks David! Advisory: ======================== Updated freerdp packages fix security vulnerabilities: FreeRDP could crash due to a NULL or invalid pointer (CVE-2013-4118, CVE-2013-4119). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4118 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4119 https://lists.opensuse.org/opensuse-updates/2016-09/msg00101.html ======================== Updated packages in core/updates_testing: ======================== freerdp-1.0.2-5.1.mga5 libfreerdp1-1.0.2-5.1.mga5 libfreerdp-devel-1.0.2-5.1.mga5 from freerdp-1.0.2-5.1.mga5.src.rpm
CC: (none) => geiger.david68210Assignee: geiger.david68210 => qa-bugs
Assessing this on x86_64 real hardware.
CC: (none) => tarazed25
Looks like a dud. Spent half the evening trying to figure out how to set up a server-client relationship before realising that when it says client it means client only. In the documentation xrdp is recommended for the server end but unfortunately that only exists in Cauldron.
You can build xrdp on mga5 (that's where I did originally), or you can use it to connect to a Windows machine if you have access to one.
s/only exists/exists only/ Nope, never ever run Windows. And I know I have done local builds but.... OK. I'll see what I can do. Thanks.
Sorry to be a pest David; not getting very far with the downloading: $ mgarepo co -d 5 xrdp svn: E170000: URL 'svn://svn.mageia.org/svn/packages/updates/5/xrdp/current' doesn't exist The /5/ is wrong so how to address cauldron? I tried '-d 6' and '-d cauldron' without success, not actually knowing what -d does, just guessing at "distribution". /etc/mgarepo.conf defaults to cauldron everywhere. $ mgarepo co -d 6 xrdp Using the svn mirror. To be able to commit changes, use 'mgarepo switch' first. svn: E170000: URL 'svn://svn.mageia.org/svn/packages/updates/6/xrdp/current' doesn't exist
Just drop the -d 5 options
Of course. That worked. What a dumbo! (typo xrpd) Let's start again. Built xrdp from Cauldron. $ magrepo co xrdp (The earlier failure was caused by a typo - xrpd) The local build succeeded but the installation required tigervnc as well. Started the xrdp service on the target machine, vega. $ sudo systemctl start xrdp.service [lcl@vega xrdp]$ sudo systemctl status xrdp.service â xrdp.service - xrdp daemon Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled) Active: active (running) since Tue 2016-10-04 00:42:03 BST; 10s ago Main PID: 24833 (xrdp) CGroup: /system.slice/xrdp.service ââ24833 /usr/sbin/xrdp --nodaemon
$ xfreerdp -T "vega central" -g 1280x1024 vega connected to vega:3389 unknown capability type 6 incorrect offset, type:0x06 actual:4 expected:5 incorrect offset, type:0x06 actual:4 expected:5 Failed to check FreeRDP file descriptor In spite of those messages the login window appeared and allowed remote login to user lcl. This created the desktop window with dimensions 1920x1080 (!). The DE defaulted to KDE with a GNOME terminal. Mate was running on the host. Simple graphical applications worked fine, called from the command line (wv and calco, homespun ruby graphical interfaces, one showing the local weather) or the system menus (konsole and imageviewer). Images were displayed properly, with very little delay (Gigabit router and ethernet connections). $ who This listed pts/0 to pts/5, all terminals running on the remote host with display :0 specified. pts/6 to pts/8 represented the "virtual" desktop and the terminal, listed against display :10.0. At some point the screensaver kicked in, the default rather than the one actually running on the remote host. So everything looked good, more or less. Moved to a wireless laptop and installed and updated freerdp. $ xfreerdp -T "vega central" -g 800x640 vega This showed the login window. Logged in remotely as lcl. The KDE desktop appeared at the correct dimensions with a GNOME terminal. Ran a few tests as before and everything looked to be working. the who command registered the six terminals already running on the remote host and two for the freerdp system. From a functional point of view these updates are good and can be pushed. No real 32bit hardware here so I am validating them.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA5-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0331.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
LWN reference for CVE-2013-4119: http://lwn.net/Vulnerabilities/702552/
added.
CC: (none) => mageia
(In reply to Nicolas Lécureuil from comment #20) > added. The LWN references are just info for the bugs. We don't use these for our advisory references.