====== X2Go Announcement on Heartbleed (CVE-2014-0160) ======
===== Announcement =====

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:
<code bash>
sudo x2gobroker-keygen
</code>
(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:
<code bash>
sudo x2gobroker-pubkeyauthorizer --broker-url http(s)://<broker-server>:<port>/<basepatch>/pubkeys/
</code>

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

===== Further Details (Not posted to the x2go-announcement list) =====

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.