This commit includes fixes for a set of 21 vulnerabilities in
rdesktop when a malicious RDP server is used.
All vulnerabilities was identified and reported by Eyal Itkin.
* Add rdp_protocol_error function that is used in several fixes
* Refactor of process_bitmap_updates
* Fix possible integer overflow in s_check_rem() on 32bit arch
* 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
There is a limiter used for processing X11 events set to 20
for slicing between processing X11 event and processing data
on file descriptors. Before this fix, when waiting for data on
filedescriptors, we assumed that there were no pending X11
events left on queue and therefore the select() timeout on
60 seconds.
Now we will check the queue and select a timeout depending
on whats left to do.
Fixes bug #275
Current approach for TS_SCardEstablishContext() causes
Windows not to detect scard reader insertion in a case
when rdesktop was lauched without attached reader(s).
Thanks to demansong@gmail.com for the help to pinpoint this issue.
Upon a redirection, we have received a cookie that is used
for authentication and we should not flag this as a pin
code for the smartcard. This solves a problem with incorrect
pin code when using smart card authentication and if
redirected to a server were a session exists.
We need to track the desired session size even if we can resize
without a reconnect. Otherwise we will request the wrong size in
the event we need to reconnect for another reason (e.g. network
problems).
If tcp_connect is called with the same server name, don't look up the
address again. This avoids connecting to other servers when using a
round-robin RDS farm name, as recommended by Microsoft.
This introduces a backwards-incompatible change. If rdesktop was
reconnecting because the user was moving between networks and the
server is no longer reachable on the same address, the user must
re-start rdesktop to reach their server.
We have seen different behaviour between versions of Windows RDP
servers how a connection should be closed and rdesktop should exit.
Windows 2008 server and earlier versions sets an error info value of
0 and then sends deactivate PDU. Later versions sends a error info
of vlaue 12 (User initiated logoff) but does not send deactivate PDU.
A work around was added to translate this case for Windows 2008 and
earlier to newer aporach to get proper handling.
This prevents reconnect loop introduced when hitting ESC or wait for
timeout at logon screen against 2008 server or earlier.
This commit also fixes a problem where a reconnect loop was triggerd
even if no required 'auto-reconnect cookie' is received from the server.
* When connecting to a Windows 2008 Server, pressing Cancel or hitting Escape while entering credentials (on the server) would lead to a reconnect if there was a resize pending.
* When connecting to a RDS farm name (round robin DNS entry as per MS recommendations), reconnecting could connect you to a different server, leading to a login screen rather than your session.
* rdesktop never had any logging that told you which address you were connecting to.
If tcp_connect is called with the same server name, don't look up the
address again. This avoids connecting to other servers when using a
round-robin RDS farm name, as recommended by Microsoft.
This introduces a backwards-incompatible change. If rdesktop was
reconnecting because the user was moving between networks and the
server is no longer reachable on the same address, the user must
re-start rdesktop to reach their server.
When a user presses cancel in the login dialog on a session on Windows
2008 R2 while a resize was pending, the user would be reconnected to
the session rather than disconnected.
A naive fix for this problem led to problems where reconnecting to
resize a session led to the user being disconnected instead.
The solution for both of these problems is to only look at the error
code sent by the server is if the connection also was deactivated at
the time of the disconnect. In just about all other cases, a
disconnect/main loop quit when the connection is active should result
in a reconnect. The sole exception is if the user closed the rdesktop
window, in case rdesktop also should exit.
We had a case on Windows 2012R2 where any early resizes would be
handled by a reconnect rather than an online resize, which led to a
bunch of follow-up problems with the session startup.
To solve this, we gave the RDPEDISP channel more time to become
established.
Co-authored-by: Henrik Andersson <hean01@cendio.com>
Co-authored-by: Karl Mikaelsson <derfian@cendio.se>
This fixes a problem where a connect loop is triggered
when a user is closing the session and there is a pending
resize triggered. When server sends error info PDU, this
means that the client should close and not enter a
reconnect due to pending resize or other reason such as
network error or redirect...
Co-authored-by: Henrik Andersson <hean01@cendio.com>
Co-authored-by: Karl Mikaelsson <derfian@cendio.se>
Co-authored-by: Thomas Nilefalk <thomas@nilefalk.se>
When dynamic session resize is disabled, leaving fullscreen should
result in a window that matches the session size.
Co-authored-by: Henrik Andersson <hean01@cendio.com>
Co-authored-by: Karl Mikaelsson <derfian@cendio.se>
When the server does not comply with our initial session size
request, we disable the dynamic session resize feature.
Co-authored-by: Henrik Andersson <hean01@cendio.com>
Co-authored-by: Karl Mikaelsson <derfian@cendio.se>
Given that a fullscreen window should have the same size as the
screen, when the server tells us a session size, then we can't
resize the fullscreen window.
Co-authored-by: Henrik Andersson <hean01@cendio.com>
Co-authored-by: Karl Mikaelsson <derfian@cendio.se>
Moving responsibility for actual resize to process_pending_resize()
Cleaning up duplicated calculation of session size
Removing handling of percentage of screen for now
Signed-off-by: Henrik Andersson <hean01@cendio.com>
Signed-off-by: Karl Mikaelsson <derfian@cendio.se>
Signed-off-by: Thomas Nilefalk <thoni56@cendio.se>
Signed-off-by: Henrik Andersson <hean01@cendio.com>
Signed-off-by: Karl Mikaelsson <derfian@cendio.se>
Signed-off-by: Thomas Nilefalk <thoni56@cendio.se>
