A CVE has been assigned for a security issue in xrdp: http://openwall.com/lists/oss-security/2017/11/23/1 A proposed fix is linked from the message above. This package also still needs to be updated and resynced with Fedora (I don't have time to do it). Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
Assigning to the registered maintainer. That's you yourself, David ;-)
CC: (none) => marja11Assignee: bugsquad => luigiwalser
Yeah I need to give it up in maintdb. Assigning to all packagers.
Assignee: luigiwalser => pkg-bugs
Suggested advisory: ======================== The updated packages fix a security vulnerability: The scp_v0s_accept function in sesman/libscp/libscp_v0.c in the session manager in xrdp through 0.9.4 uses an untrusted integer as a write length, which allows local users to cause a denial of service (buffer overflow and application crash) or possibly have unspecified other impact via a crafted input stream. (CVE-2017-16927) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16927 http://openwall.com/lists/oss-security/2017/11/23/1 ======================== Updated package in 6/core/updates_testing: ======================== xrdp-0.9.4-1.mga6 xrdp-devel-0.9.4-1.mga6 from SRPMS: xrdp-0.9.4-1.mga6.src.rpm
Whiteboard: MGA6TOO => (none)Assignee: pkg-bugs => qa-bugsCC: (none) => nicolas.salgueroStatus: NEW => ASSIGNEDSource RPM: xrdp-0.9.1-4.mga7.src.rpm => xrdp-0.9.1-3.mga6.src.rpmVersion: Cauldron => 6
Having a go at this on Mageia 6 :: x86_64 Updated xrdp, which pulled in tigervnc-server. Initially I expected this to act a bit like ssh but in fact it is far more complicated. Most of the information on the internet is extremely confusing for an absolute beginner. I got as far as enabling port 3389/tcp and starting the xrdp service. $ systemctl status xrdp.service ● xrdp.service - xrdp daemon Loaded: loaded (/usr/lib/systemd/system/xrdp.service; enabled; vendor preset: Active: active (running) since Mon 2017-12-18 23:24:42 GMT; 47min ago Docs: man:xrdp(8) man:xrdp.ini(5) Main PID: 18057 (xrdp) CGroup: /system.slice/xrdp.service └─18057 /usr/sbin/xrdp --nodaemon Used useradd to add suzy and zack as users. Added two vnc service users to /etc/sysconfig/vncserver VNCSERVERS="1:suzy 2:zack" VNCSERVERARGS[1]="-geometry 1200x800 -nolisten tcp -localhost" VNCSERVERARGS[2]="-geometry 1200x800 -nolisten tcp -localhost" Restarted xrdp. I have no idea what the relationship is between xrdp and tigervnc but suspect it has something to do with vncserver. Neither tigervnc nor tigervnc-server can be started as a service. There is mention of a vncviewer in man pages and on the web but I cannot find that anywhere. Tried $ vncserver New 'vega:3 (lcl)' desktop is vega:3 Starting applications specified in /home/lcl/.vnc/xstartup Log file is /home/lcl/.vnc/vega:3.log $ cd .vnc $ cat xstartup #!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /etc/X11/xinit/xinitrc No clue what this means. How do I start up a remote session for suzy or zack, on one of my other machines for example? $ vncserver suzy usage: vncserver [:<number>] [-name <desktop-name>] [-depth <depth>] [-geometry <width>x<height>] [-pixelformat rgbNNN|bgrNNN] [-fp <font-path>] [-cc <visual>] [-fg] [-autokill] [-noxstartup] [-xstartup <file>] <Xvnc-options>... vncserver -kill <X-display> vncserver -list $ vncserver :2 A VNC server is already running as :2 $ su suzy Password: su: Authentication failure The password just set is not recognized. And where does one specify the remote address? Apologies to all and sundry. This is all too much for my tiny brain.
CC: (none) => tarazed25
xrdp uses VNC behind the scenes, but that's a mostly unimportant technical detail. Once you have xrdp running, use an RDP client (like rdesktop or freerdp) to connect to it.
More research then. Thanks. This is confusing too: # vncserver :2 A VNC server is already running as :2 # vncserver -list TigerVNC server sessions: X DISPLAY # PROCESS ID :1 12579 Note the :1 What I need to find is a tutorial which covers every single step from zero to a remote desktop session. I know nothing, but nothing. ssh is so easy.
I tried this but it is shooting in the dark. It blanked. $ rdesktop -u lcl -d 192.168.1.156 server :3389 What is 'domain' in this context?
Also, I was assuming that the user does not need to exist on the remote machine but that could be wrong.
I tried the remote desktop viewer in the system menu but have not got very far with it. It has an RDP protocol option. It shall have to wait until the evening now.
Don't run tigervnc! It'll do that for you. Just run xrdp and connect to it.
Yes, use the viewer with the RDP protocol. Yes, you will need to authenticate as a user on the machine you're connecting to, just like with SSH. The domain option is as in an Active Directory domain if you're using that (as would often be the case if the RDP server was actually a Windows machine, which it usually is). For your case you shouldn't need that option.
Thanks for the tips David. Busy day ahead so shall pick up the traces later.
Created attachment 9843 [details] tail end of journal during attempted remote desktop session
Remote Desktop Viewer: remote -> connect -> protocol = RDP set host to another machine on the LAN using either host name or IP address named user = lcl or suzy or zack Left domain blank Hit connect -> "Error connecting to host" It works fine with the SSH protocol. Must be a configuration problem.
Is the host you're connecting to the one running xrdp?
No.
To be sure: $ systemctl status xrdp Failed to dump process list, ignoring: Unit xrdp.service not found. ● xrdp.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
Xrdp is an RDP server. You need to connect to it from another machine with an RDP client like rdesktop or freerdp.
Multiple thanks David. I would never have figured that out. As I said, the documentation is ultra confusing for a beginner.
It probably assumes that you are familiar with RDP from the Windows world. I imported this package and then determined that x11vnc was a better solution for the problem I was trying to solve. I would have dropped it but someone else was interested in it (maybe Barry).
It all looks obvious now. Once the server connection was established the remote desktop appeared; logged in and everything worked (except audio of course) and the response to keyboard events was practically instantaneous. It was possible to view a video on the target machine using a file on this machine shared over the network. If this test is enough the package is fine for 64 bits in Mageia 6.
Whiteboard: (none) => MGA6-64-OK
Heroic work, Len. Advisoried & validating.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0456.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED