Unauthorized Host Access Vulnerability (cve-1999-0526) and Xmanager

All X servers, including Xmanager, have a vulnerability that allows unauthorized X applications to access them. This can allow unauthorized users to record keystrokes and take screenshots of the Xserver. You can read more about this vulnerability (cve-1999-0526) here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-1999-0526.

This is not a bug nor a missing protocol. Options that block any unauthorized access were developed: host access control (xhost control) and XDMCP connection's cookie based control.

To combat this vulnerability and keep you secure, Xmanager also utilizes access control and cookie based control options which are turned on by default. On top of these options, if the SSH protocol is used, a much stronger and robust access control can be utilized. This guide will go over the possible situations in which remote X applications attempt to connect to Xmanager.

Figure A

In Figure A above, you can see there are four separate access attempts. Only Case 1 is an authorized attempt. The user is authorized and this connection attempt is wanted. Case 2, 3, and 4 are unauthorized attempts. These are access attempts the user does not recognize nor wants connecting to his/her Xmanager. Note that the access attempts are blocked in the Figure. Any access attempts from different remote hosts falls under these conditions. We'll go over each case below.

Case 1: An Authorized Connection

The user, 'test,' below is an authorized user that connected to the SSH server. Xclock attempted to connect to the SSH server's local port with the correct cookie and therefore succeeded. The locolhost: 10.0 indicates local TCP port 6010.

Case 2: An Unauthorized Connection

The user, 'test2,' below is attempting an unauthorized connection to the SSH server. Xclock tried to connect to the SSH server's local port, but with an incorrect cookie and therefore Xclock correctly failed.

Case 3: Plain TCP Connection with Firewall Blocking

Case 3 indicates a direct plain TCP connection that attempts to connect to Xmanager using an external port (192.186.1.123:0) binding, not a local binding. However, it is blocked by a firewall system before a connection can be established.

This case can actually be either an authorized or unauthorized attempt. If the firewall is actively blocking the X11 ports, all X11 connections, authorized or not, will not be allowed.

Case 4: Plain TCP Connection without Firewall

This case is a plain TCP connection that attempts to connect to Xmanager using an external port binding, not a local binding. It is not blocked by the firewall so the connection succeeded. However, Xmanager recognizes that this connection is unauthorized. Xmanager's Access Control feature will display the prompt below:

If you select 'No,' the packets for Xclock will be refused. Case 4, like Case 3, can be either an authorized or unauthorized connection attempt. The Access Control feature is enabled by default.

Utilizing the security features we've gone over above, you can grant access only to authorized users. If you are using Xmanager over the internet or in an unreliable environment, we suggest that you always use an SSH connection and also enable Host Access Control.