| Summary: | freerdp new security issues CVE-2013-4118 and CVE-2013-4119 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | geiger.david68210, mageia, sysadmin-bugs, tarazed25 |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lwn.net/Vulnerabilities/702121/ | ||
| Whiteboard: | MGA5-64-OK | ||
| Source RPM: | freerdp-1.0.2-5.mga5.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2016-09-28 22:27:22 CEST
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.david68210 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 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.
Len Lawrence
2016-10-04 03:43:44 CEST
Keywords:
(none) =>
validated_update An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0331.html Status:
NEW =>
RESOLVED LWN reference for CVE-2013-4119: http://lwn.net/Vulnerabilities/702552/ (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. |