NX ist ein populärer Remote-Desktop-Dienst, der ursprünglich kommerziell von No Machine ins Leben gerufen wurde. Damit lassen sich grafische Oberflächen entfernter Rechner effizient lokal darstellen. Qtnx ist eine der zahlreich NX-Client-Applikationen, mit denen Linux-Anwender eine NX-Verbindung aufbauen können. Durch eine Unachtsamkeit beim Schutz der Konfigurationsdatei kann ein lokaler Angreifer an den privaten Schlüssel zum Initialisieren von NX-Sessions gelangen.

Die NX-Technologie verwendet zur eigentlichen Datenkommunikation eine SSH-Verbindung, um ein möglichst hohes Maß an Sicherheit zu gewährleisten. Die Geschwindigkeitssteigerung von NX gegenüber herkömmlichen X11- oder Virtual Network Computing (VNC)-Verbindungen kommt vor allem durch Datenkompression, Caching zuvor übertragener Daten und die Reduktion von Roundtrips zustande. NX schaltet sich dazu zwischen die X11-Hosts und optimiert und sichert deren Kommunikation. Obwohl NX ursprünglich für X11-Verbindungen erdacht wurde, kann es mittlerweile auch als Proxy Server zum Tunneln von Windows-RDP (Remote Desktop Protocol) und VNC verwendet werden. Ein großer Vorteil beim Arbeiten mit NX ist, dass sich Sessions unterbrechen und später wieder fortgesetzen lassen.

Auf jedem NX-Server wird ein Benutzer namens “nx” angelegt, der am Anfang einer NX-Session verwendet wird um die Authentifikation und das Starten der Session durchzuführen. Der “nx”-Benutzer hat allerdings keinen Standard-Shellzugriff – er wird lediglich für diese Initialisierung benötigt. Zur NX-Authentifikation verwendet NX ein DSA-Schlüsselpaar, wobei der Server den öffentlichen Schlüssel und der Client den privaten Schlüssel kennen muss. Oft wird beim Aufsetzen des NX Servers der mitgelieferte DSA-Schlüssel verwendet, denn das Paket enthält schon einen privaten und öffentlichen DSA-Schlüssel. Der private Schlüssel muss dann auf alle Clients kopiert werden, die auf den NX-Server zugreifen wollen.

Dies ist im Prinzip nicht weiter kritisch, da das DSA-Schlüsselpaar lediglich zur Authentifikation des Benutzers “nx” verwendet wird. Danach wird eine verschlüsselte Verbindung aufgebaut und erst über diese findet dann die Authentifikation des effektiven Benutzers statt. Wer sich für die genauen Details der Initialisierung interessiert kann, kann “nxssh” verwenden, um eine Verbindung mit dem NX-Server aufzubauen und sich die einzelnen Schritte ansehen.

Neben dem Standardschlüssel bietet NX dem Anwender auch die Möglichkeit, selbst ein Schlüsselpaar zu erzeugen. In diesem Fall muss der Client den entsprechenden privaten Schlüssel aber explizit in seine Konfiguration aufnehmen. Qtnx speichert diesen Schlüssel, wie andere Konfigurationsdaten auch, im Verzeichnis”~/.qtnx/” in “*.nxml”-Dateien, wo die Werte für verschiedene Option-Keys gesetzt werden. Darunter befindet sich auch ein Eintrag für den Authentifikationsschlüssel:

<option key="Authentication Key" value=""></option>

Der Wert ist leer, da in diesem Fall mit dem Standardschlüssel gearbeitet wird. Kommt aber ein eigenes DSA-Schlüsselpaar zum Einsatz, so wäre für “value” hier der private DSA-Schlüssel eingetragen. Sollte der Client diese Extrasicherheit in Form eines eigenen DSA-Schlüssels wünschen, ist es natürlich sinnvoll, dass kein anderer lokaler Benutzer des Systems diesen privaten Schlüssel auslesen kann. Und hier hat sich nun ein kleines Problem bei den Rechten der Konfigurationsdatei eingeschlichen, denn jeder lokale Benutzer kann diese Datei lesen, wenn das Home-Verzeichnis nicht extra abgesichert ist:

drwxr-xr-x 2 mark mark 4096 2011-08-14 14:05 .qtnx

und

mark@tux:~/.qtnx$ ls -l
total 8
-rw-r--r-- 1 mark mark 1222 2010-07-19 11:59 FAShome.nxml
-rw-r--r-- 1 mark mark 1197 2010-12-01 12:31 FASwork.nxml

Das hierdurch entstehende Sicherheitsrisiko ist allerdings gering, da selbst mit bekanntem privaten Schlüssel immer noch die gleiche Sicherheit wie bei Standardschlüsseln gegeben ist. Trotzdem sollte der Qtnx-Client natürlich dafür sorgen, dass diese Konfigurationsdateien ordentlich geschützt sind. Ein Anwender kann dies notfalls händisch via “chmod o-r” beziehungsweise “chmod o-x”
erledigen.