it-swarm-eu.dev

Sicherheitsbedenken bei der X11-Weiterleitung

Was sind einige der Sicherheitsbedenken und Gründe für oder gegen das Zulassen der X11-Weiterleitung? Ich habe im Allgemeinen den Ansatz gewählt, dies nicht unter dem Deckmantel der Sicherheit zuzulassen. Kürzlich hatte ein Benutzer angegeben, dass die Sicherheitsaspekte, die sich aus dem Zulassen von weitergeleiteten X11-Sitzungen ergeben, vernachlässigbar sind. Ich war neugierig, mehr darüber zu erfahren, was der Schaden beim Zulassen der X11-Weiterleitung ist und warum man es möglicherweise zulassen möchte.

29
John

Die X11-Weiterleitung impliziert, dass ein Kanal vom Server zurück zum Client geöffnet wird. In einer einfachen SSH-Sitzung ist der Client vertrauenswürdiger als der Server: Jeder, der die Kontrolle über den Client hat, kann Befehle auf dem Server ausführen (unter der Annahme eines Shell-Zugriffs), aber das Gegenteil ist nicht der Fall. Bei der X11-Weiterleitung erhält der Server wahrscheinlich Shell-Zugriff auf den Client.

In einer Textsitzung gibt es einen begrenzten Kanal vom Server zurück zum Client: Der Server bestimmt die Ausgabe, die auf dem Client angezeigt wird, und kann insbesondere versuchen, Escape-Sequenzen in dem auf dem Client ausgeführten Terminal auszunutzen.

In einer X11-Sitzung kann der Server X11-Befehle an den Client zurücksenden. X11 wurde nicht mit Blick auf die Sicherheit entwickelt, sondern mit dem Gedanken, dass alle Programme, die Sie anzeigen, von Ihnen ausgeführt werden und daher trotzdem vertrauenswürdig sind. Standardmäßig unterwirft SSH Befehle vom Server Einschränkungen über die Erweiterung X11 SECURITY-Erweiterung . Die SECURITY-Erweiterung deaktiviert einige offensichtliche Angriffe wie Tastaturgriffe und Tasteninjektion, ermöglicht jedoch andere wie das Stehlen von Fokus.

Angenommen, ich öffne eine SSH-Verbindung zu someserver mit aktivierter X11-Weiterleitung. Das Hauptrisiko besteht darin, dass someserver, wenn someserver bösartig ist, alle möglichen bösen Dinge mit den Fenstern/Anwendungen tun kann, die ich auf meinem eigenen Computer geöffnet habe.

Zum Beispiel kann someserver Fenster auf meinem Computer öffnen, andere Fenster schließen, die ich geöffnet habe, kann den Inhalt anderer Fenster ausspionieren, die ich geöffnet habe, kann die Schlüssel ausspionieren, die ich in andere Fenster eingebe, kann injizieren gefälschte Tastenanschläge und Mausereignisse in andere Fenster, die ich geöffnet habe, und im Allgemeinen nur mit jedem anderen Fenster, das ich auf meinem Computer geöffnet habe, durcheinander - selbst wenn einige dieser anderen Fenster lokale Anwendungen sind, die lokal ausgeführt werden.

7
D.W.

Eine Lösung für die in den anderen Antworten diskutierten Risiken der X-Weiterleitung über ssh wäre die Verwendung eines sogenannten Masquerade X-Servers, der eigentlich kein X-Server ist, der Client-Software jedoch eine Pseudo-X-Schnittstelle und einen Pseudo-X-Bildschirm bietet auf dem Container, während einige X-Arbeiten an den dahinter liegenden echten X-Server übergeben werden. Der Pseudo-X-Bildschirm wird als einzelnes X-Fenster auf dem tatsächlichen X-Desktop des Hosts angezeigt.

Obwohl es nicht als Sicherheitstool gedacht war, passt Xephyr zu dieser Beschreibung.

Aus diesem Grund habe ich ein Javascript-Programm geschrieben, um aus einem Vanilla-Ubuntu-Image einen lxd/lxc-Container zu erstellen und ihn mit Firefox, openvpn, Xephyr und pusleaudio zu füllen.

https://github.com/craigphicks/browser-on-lxc-vpn-xephyr

https://www.npmjs.com/package/browser-on-lxc-vpn-xephyr

Ich würde keine starken Sicherheitsansprüche geltend machen - es war eine Proof-of-Concept-Übung.

0
Craig Hicks