I originally sent this email to x2go-announcements@lists.x2go.org on 2014-05-08 (UTC Time.) I am re-sending the email now because there was an issue that prevented x2go-announcements@lists.x2go.org from being synced with GMANE.org.

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

Michael DePaulo X2Go Developer