Bug 24192

rdesktop 1.8.4 has been pushed to Cauldron.

Advisory
========

rdesktop has been updated to fix multiple CVE's.

Fix memory corruption in process_bitmap_data - CVE-2018-8794
Fix remote code execution in process_bitmap_data - CVE-2018-8795
Fix remote code execution in process_plane - CVE-2018-8797
Fix Denial of Service in mcs_recv_connect_response - CVE-2018-20175
Fix Denial of Service in mcs_parse_domain_params - CVE-2018-20175
Fix Denial of Service in sec_parse_crypt_info - CVE-2018-20176
Fix Denial of Service in sec_recv - CVE-2018-20176
Fix minor information leak in rdpdr_process - CVE-2018-8791
Fix Denial of Service in cssp_read_tsrequest - CVE-2018-8792
Fix remote code execution in cssp_read_tsrequest - CVE-2018-8793
Fix Denial of Service in process_bitmap_data - CVE-2018-8796
Fix minor information leak in rdpsnd_process_ping - CVE-2018-8798
Fix Denial of Service in process_secondary_order - CVE-2018-8799
Fix remote code execution in in ui_clip_handle_data - CVE-2018-8800
Fix major information leak in ui_clip_handle_data - CVE-2018-20174
Fix memory corruption in rdp_in_unistr - CVE-2018-20177
Fix Denial of Service in process_demand_active - CVE-2018-20178
Fix remote code execution in lspci_process - CVE-2018-20179
Fix remote code execution in rdpsnddbg_process - CVE-2018-20180
Fix remote code execution in seamless_process - CVE-2018-20181
Fix remote code execution in seamless_process_line - CVE-2018-20182

References
==========

https://github.com/rdesktop/rdesktop/releases/tag/v1.8.4
https://security-tracker.debian.org/tracker/CVE-2018-20182
https://security-tracker.debian.org/tracker/CVE-2018-20181
https://security-tracker.debian.org/tracker/CVE-2018-20180
https://security-tracker.debian.org/tracker/CVE-2018-20179
https://security-tracker.debian.org/tracker/CVE-2018-20178
https://security-tracker.debian.org/tracker/CVE-2018-20177
https://security-tracker.debian.org/tracker/CVE-2018-20176
https://security-tracker.debian.org/tracker/CVE-2018-20175
https://security-tracker.debian.org/tracker/CVE-2018-20174
https://security-tracker.debian.org/tracker/CVE-2018-8800
https://security-tracker.debian.org/tracker/CVE-2018-8799
https://security-tracker.debian.org/tracker/CVE-2018-8798
https://security-tracker.debian.org/tracker/CVE-2018-8797
https://security-tracker.debian.org/tracker/CVE-2018-8796
https://security-tracker.debian.org/tracker/CVE-2018-8795
https://security-tracker.debian.org/tracker/CVE-2018-8794
https://security-tracker.debian.org/tracker/CVE-2018-8793
https://security-tracker.debian.org/tracker/CVE-2018-8792
https://security-tracker.debian.org/tracker/CVE-2018-8791

Files
=====

Uploaded to core/updates_testing

rdesktop-1.8.4-1.mga6

from rdesktop-1.8.4-1.mga6.src.rpm

Assignee: smelror => qa-bugs

MGA6-32 MATE on IBM Thinkpad R50e
No installation issues
First tried to get into Win10 on my Lenovo laptop, but found our that rdp does not work on it being a Home edition, unless you break the Win license.
Tried to a Win XP Pro in a VM on my desktop PC, and that worked OK. I could ping the network from the remote desktop on the VM to the local PC.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA6-32-OK

Thought I would try this but cannot get the connection working.  There is no good documentation about this application - it is all preaching to the converted, as so much documentation does.  What we need is something that starts at first principles to give a newbie a grasp of what is going on.  rdesktop is described as a "client" but it cannot be started without specifying server:xxxx on the command line.  Since rdesktop is a client I would assume that this construction is saying - find the server via this port (3389 in this case).  That leaves the question, how does this help identify the target machine?  The only option for identifying a host is -n which is "client hostname".  Now if the client is your own machine how does that get you anywhere?  If you use the target hostname the command simply times out.
    $ rdesktop -n vega -u lcl -p - server:3389
    Autoselected keyboard map en-gb
    Password: 
    ERROR: server: unable to connect

Note that I managed to get xrdp running at the other end - no help.

CC: (none) => tarazed25

Also tried Remote Desktop Viewer in the menus.  Browsing the local network returned nothing.  Specifying a local host brought up a blank black screen.
Tried it again but selected a bookmark from previous uses and that showed a terminal screen with command prompt.  No desktop though.

Note that Remote Desktop Viewer uses vinagre which lists rdesktop as one of its requirements.

Updated the package and tried vinagre again.  No change there; a raw local connection shows a blank black screen.  Clicking on a bookmark produced a terminal only.

Going to forget about rdesktop on the command line.

Handing this back to QA.  Baffled.

@ Len
I wonder if you're on the right track. To me rdesktop is a specific application to get to the remote desktop facility of Windows. With the restriction as I stated above, that it only works with the Windows Pro (or Enterprise or whatever the moer expensive variants are called) version, not wit a Home version.
So no need to go hunting for a "server". And AFAICS the remote desktop is open by default in Win.
In my case, I got it working at the CLI with the command:
rdesktop -u herman 192.168.2.11
i.e. the IP address I defined for my WinXP PRO virtual box, that's all there is to it.

Note also that graphical applications could be launched from the command-line on the remote desktop.

OK Herman, tried that and got the login dialogue with session = Xvnc displayed.

$ rdesktop -u lcl vega
Autoselected keyboard map en-gb
Connection established using SSL.

It went no further than that - the login screen remained, even after clicking on OK.
ERROR: SSL_read: 5 (Connection reset by peer)
Disconnected due to network error, retrying to reconnect for 70 minutes.
Connection established using SSL.

xrdp was dead at the other end.

I copy from the description of the rdesktop package as seen in MCC:

rdesktop is an open source client for Windows NT Terminal Server and Windows 2000 Terminal Services, capable of natively speaking Remote Desktop Protocol (RDP) in order to present the user's NT desktop. Unlike Citrix ICA, no server extensions are required.

And the package has only one executable: rdesktop.
So I don't get what you are doing there with Xvnc and xrdp, it does not apply.

@Herman, comment 10.  Granted, the application is targeted at Windows but as I do not have Windows (it is not allowed in the house) I was trying to demonstrate that it could connect to another host running RDP.  Since an RDP service does not run by default on Linux I was trying to set it up using xrdp and in one experiment by running another instance of rdesktop.  Basically, I do not know what I am doing.

Well, I am not an expert in this business. But you suppose that some other Linux program would behave exactly as Win does. If that would be the case, I wonder why then at Linux side you would need a program specific for this Windows rdp.
I come under the impression the Win rdp and the rdp servers on Linux are very different beasts.

You can use rdesktop to connect to any RDP server, be it Windows or xrdp, and they're really not much different at all.  The rdesktop man page is very helpful for finding the right command line options.  It's not very complicated.

CC: (none) => luigiwalser

You can use rdesktop to connect to any RDP server, be it Windows or xrdp, and they're really not much different at all.  The rdesktop man page is very helpful for finding the right command line options.  It's not very complicated.

@David, re comment 14.  Not very complicated for you maybe - that is what I meant about preaching to the converted.  It is still not clear to me what is needed on the target machine to allow it to be connected to rdesktop.  It looks like you need more than xrdp running or else more expertise about using it (xrdp).
I chose the command-line options which seemed relevant but still could not make a connection.

Trying again:
$ rdesktop -u lcl vega:3389 
Autoselected keyboard map en-gb
Connection established using SSL.

This brings up the login dialogue for vega with the xrdp logo with the "just connecting" label.
The reason it will not connect is that I cannot get xrdp to run on the target machine.
$ sudo systemctl start xrdp
$ systemctl status xrdp
... failed ...

It was running earlier in one of my experiments but fell over at some point.

Noticed that there was a service xrpd-sesman available so started that at the target end (vega).  It was already running at the test end.  That did not help either.  UDP and TCP ports open.  xrdp.ini on vega looked OK - the listener port was set to 3389.

Advisory done from comment 2. I took the CVEs from the description (21) rather than their refs (19). Unimportant: their references are added by the system from their numbers.

@Len: Whether you win or give up, please then validate the update. Herman's test comment 3 is good.

Keywords: (none) => advisory
CC: (none) => lewyssmith

Noticed that the session manager service also has a .ini file.  Changed the port number and restarted the xrdp and xrdp-sesman services on the target machine.
This time the connection was established but got no further than displaying a blank screen which responded to nothing.
There is obviously more to this than meets the eye so , following the advice from Lewis am validating this on the basis of the successful 32-bit test.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0041.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Debian has issued an advisory for this on February 18:
https://www.debian.org/security/2019/dsa-4394

Summary: rdesktop multiple CVE's, CVE-2018-8794 CVE-2018-8795 CVE-2018-8797 CVE-2018-20175 CVE-2018-20176 CVE-2018-87[91-93] CVE-2018-8796 CVE-2018-8[798-800] CVE-2018-20174 CVE-2018-201[77-82] => rdesktop new security issues CVE-2018-879[1-9], CVE-2018-8800, CVE-2018-2017[4-9], CVE-2018-2018[0-2]