The following is the X2Go project's announcement on heartbleed (CVE-2014-0160) and what actions users & system administrators should take.

1. When X2Go (both X2Go Client and X2Go Server) is used without an X2Go Session Broker, X2Go is not vulnerable.

If you do use X2Go without a session broker, no action is required in terms of X2Go.

We still strongly advise you to install your Linux distro's patch for OpenSSL.

We also advise updating X2Go Client for Windows to 4.0.2.0, and X2Go client for Mac OS X to 4.0.2.0, in order to avoid vulnerability scanners flagging X2Go Client as vulnerable.

2. When X2Go is used with an X2Go Session Broker, these X2Go components are vulnerable if the following conditions are met:

a. X2Go Session Broker: If the Linux distro uses OpenSSL 1.0.1, the Linux distro's CVE-2014-0160 patch is not installed, and HTTPS is enabled. (If you are using x2gobroker-wsgi, HTTPS would be enabled in your apache configuration. If you are using x2gobroker-daemon, it would be enabled in /etc/default/x2gobroker-daemon .)

b. X2Go Client for Linux: If the Linux distro uses OpenSSL 1.0.1, the Linux distro's CVE-2014-0160 patch is not installed, and HTTPS is used to connect to an X2Go Session broker.

c. X2Go Client for Windows: If X2Go Client is at version 4.0.1.3+build2, and HTTPS is used to connect to the X2Go Session Broker.

d. X2Go Client for Mac OS X: If X2Go Client is at version 4.0.1.3 or earlier, and HTTPS is used to connect to the X2Go Session Broker.

e. PyHoca-GUI for Linux: If you are using a nightly build since 2014-03-18 (when broker support was 1st added,), the Linux distro uses OpenSSL 1.0.1, the Linux distro's CVE-2014-0160 patch is not installed, HTTPS is used to connect to an X2Go Session broker.

f. PyHoca-CLI for Linux: If you are using a nightly build since 2014-03-03 (when broker support was 1st added,) the Linux distro uses OpenSSL 1.0.1, the Linux distro's CVE-2014-0160 patch is not installed, HTTPS is used to connect to an X2Go Session broker. (No released versions of PyHoca-GUI or PyHoca-CLI are vulnerable. Mac OS X builds and Windows builds have not been released for these nightly versions, only Linux builds have.)

If you meet the aforementioned conditions, we recommend the following. Note that we recommend following the instructions even if you have installed the Linux distro's OpenSSL patch in a timely manner:

X2Go Session Broker:

a. Install your Linux distro's patch for OpenSSL (CVE-2014-0160) if you haven't done so already.

b. Replace the SSL certificate used by X2Go Session Broker. Consult your Linux distro's instructions on doing so. If you are using x2gobroker-wsgi (X2Go Session Broker with Apache2 via the WSGI interface), the path to the SSL cert is specified in the Apache2 configuration. The SSL cert is auto-generated by default for apache2. If you are using x2gobroker-daemon, the path to the SSL cert is specified in /etc/default/x2gobroker-daemon .

c. Reset the passwords for any user accounts that have been used with an X2Go Session Broker before the patch was installed.

d. Replace the SSH key used by X2Go Session Broker to communicate with X2Go Session Broker Agents:

sudo x2gobroker-keygen

(To clarify, the SSH connection between an X2Go Session Broker and an X2Go Session Broker Agent (running on an X2Go Server) is not vulnerable. However the SSH private key used to communicate with agents is in the broker's memory. Therefore, the broker could leak the key to an X2Go Client that accesses the broker over HTTPS. In contrast, the SSH private key used to communicate with X2Go clients is not in the broker's memory, so it does not need to be replaced.)

X2Go Server (follow these instructions if X2Go Session Broker was vulnerable):

a. Reset the passwords for any user accounts that have been used with an X2Go Session Broker before the patch was installed.

b. If you have the X2Go Session Broker Agent installed, authorize the new X2Go Session Broker SSH key:

sudo x2gobroker-pubkeyauthorizer --broker-url http(s)://<broker-server>:<port>/<basepatch>/pubkeys/

X2Go Client:

a. Patch X2Go Client, if you haven't already done so. On Linux, install your Linux Distro's patch for OpenSSL (CVE-2014-0160). On Windows, update X2Go Client to 4.0.2.0. Consult this page if you require info on what has changed since 4.0.1.3+build2: http://wiki.x2go.org/doku.php/doc:release-notes-mswin:x2goclient-4.0.2.0 On Mac OS X: update X2Go Client to 4.0.2.0.

b. Replace all SSH private key / public key pairs that are used by X2Go Client to connect to an X2Go Session Broker, or to connect to an X2Go server. (To clarify, the SSH connection between an X2Go Client and an X2Go server is not vulnerable, but the SSH private key can be in the client's memory. The client could connect to an X2Go Session Broker over HTTPS, and then leak SSH private keys to the X2Go Session Broker.)

PyHoca-GUI & PyHoca-CLI

a. Patch PyHoca-GUI/PyHoca-CLI by installing your Linux Distro's patch for OpenSSL (CVE-2014-0160).

b. Replace all SSH private key / public key pairs that are used by PyHoca-GUI/PyHoca-CLI to connect to an X2Go Session Broker, or to connect to an X2Go server. (To clarify, the SSH connection between an PyHoca-GUI/PyHoca-CLI and an X2Go server is not vulnerable, but the SSH private key can be in the client's memory. The client could connect to an X2Go Session Broker over HTTPS, and then leak SSH private keys to the X2Go Session Broker.)

Fore the full technical details on why the X2Go Project is making these recommendations, follow this link:

http://wiki.x2go.org/doku.php/security:cve-announcements:heartbleed

Below is what the X2Go Project has determined that lead us to make our recommendations:

1. The SSH protocol, and its numerous implementations, are not affected at all. This is despite the fact that the majority of them link against OpenSSL. The answer by “simme” to this ServerFault question explains why: http://serverfault.com/questions/587433/heartbleed-are-services-other-than-https-affected

2. Linux, Windows (2000/XP and later) and Mac OS X all have a very important operating system security feature called “memory protection.” Some heartbleed articles have misused that term, but it is actually a very specific computer science term. A process that is affected by heartbleed cannot read another process's memory, even if that other process is linked against the same vulnerable OpenSSL library. The original process therefore cannot leak the other process's memory. See the answer by “jpetazzo” here: http://stackoverflow.com/questions/23041744/does-docker-contain-the-heardbleed-exploit

3. X2Go Server uses openssh sshd across all Linux distros. SSH is not affected for the aforementioned reason.

4. X2Go Server also uses sshfs for folder sharing across all Linux distros. SSH is not affected for the aforementioned reason.

5. The X2Go session broker and the X2Go Session Broker Agents (running on the X2Go Servers) communicate with eachother via SSH connections using the paramiko library for SSH. Therefore, the X2Go Session Broker Agent is not affected, and X2Go Session broker is not affected in terms of communicating with the X2Go Session Broker Agents (the X2Go Servers.) However, the SSH private key used by the X2Go Session Broker to communicate with with agents is in the X2Go Session Broker's memory. Therefore, based on the next piece of information, we are recommending that system administrators replace said key.

6. The X2Go session broker can be accessed by an X2Go Client over HTTP, HTTPS, or SSH. SSH is not affected for the aforementioned reason. HTTPS is affected when the operating system's patch is not installed, both over x2gobroker-wsgi and over x2gobroker-daemon. Both X2Go Client and the X2Go Session Broker are affected over the HTTPS connection.

7. One piece of important information that can be contained in the memory of X2Go Session Broker, and in the memory of X2Go client when it accesses an X2Go Session Broker, is the user's password. That is why we are recommending that system administrators reset user passwords.

8. Another piece of important information that can be contained in the memory of X2Go Session Broker, and in the memory of X2Go client when it accesses an X2Go Session Broker, is the temporary SSH private key used for the Auto-Login feature. Again, this is only a temporary key. After the X2Go Client connects to the X2Go Server, the X2Go Session Broker Agent automatically removes the public key from .ssh/authorized_keys within seconds. Therefore, there is only a very small window when an attacker could have used this key. As a precaution, we are recommending that the user's password be changed on the X2Go Server, since an attacker could have reset the user's password after connecting to the X2Go Server as the user.

9. One piece of important information that can be contained in the memory of X2Go Client when it accesses an X2Go session broker are the permanent private SSH keys used by the X2Go Client. By “permanent”, we mean keys that already exist on disk. These permanent private keys are presumably generated by the user, or the client OS. The permanent private keys are never in the memory of the X2Go Server or the X2Go Session Broker, nor are they ever sent over the wire, but in they are in the memory of the X2Go Client. Even when Auto-Login is used with a permanent SSH private key / public key pair, the X2Go Client only sends public key, not the private key. Still, the fact that the private key is in the X2Go Client's memory makes us recommend that you regenerate any SSH private keys used by X2Go client, if the client ever connects to an X2Go session broker over HTTPS.

10. X2go Client uses openssh sshd for file sharing. It is not affected for the same reason as libssh.

11. X2Go Client for Mac OS X usses OpenSSL 1.0.1. The library is called libssl.1.0.0.dylib, but it is actually OpenSSL 1.0.1. The library has been patched in X2Go Client 4.0.2.0 for Mac OS X.

12. The 1st version of x2goclient for windows to have session broker support actually work over HTTPS is 4.0.1.3+build2, because we bundled both ssleay32.dll and libeay32.dll. Previously (including the original 4.0.1.3) we bundled only libeay32.dll, and https session broker support therefore never worked. This vulnerability has been fixed in x2goclient 4.0.2.0 because the openssl .DLLs have been updated to 1.0.1g. The openssl .DLLs come from this site. Numerous other software projects bundle the same .DLLs: http://slproweb.com/products/Win32OpenSSL.html Also, note that even if users never use HTTPS session broker support, or have 4.0.1.3 or earlier installed, vulnerability scanners (e.g., Secunia PSI, Mcafee Vulnerability Manager) are likely to flag the .DLL(s). The updated .DLLs in x2goclient 4.0.2.0 will satisfy vulnerability scanners.

13. For File sharing with the windows X2Go Client, we use cygwin's openssh sshd.exe, which in turn uses openssl. Again, SSH is not affected for the aforementioned reason. However the 1 of the vulnerable 2 cygwin DLLs exists in the x2gofolder for x2goclient 4.0.1.3+build2 and prior versions: cygcrypto-1.0.0.dll (cygssl-1.0.0.dll is the vulnerable .DLL that is not bundled and therefore does not exist on disk) (Yes, the .DLL files have 1.0.0 in their name, but are actually 1.0.1). (From binary package name “libopenssl100”) Once again, the problem is that vulnerability scanners are likely to flag it. The .DLL has been updated with the fix (openssl 1.0.1.g) in x2goclient 4.0.2.0, so that will satisfy vulnerability scanners.

14. X2Go Session broker has an authentication mechanism called https_get_authmech, where X2Go Session Broker tests the user's password against an HTTPS server. This connection would be vulnerable. Hence why we are recommending resetting passwords on the X2Go Session Broker and regenerating its SSL certificate

15. The latest stable releases of PyHoca-GUI (0.4.0.9) and PyHoca-CLI (0.4.0.2) did not include broker support. Therefore, they are not affected. The current nightly builds do though.