it-swarm.com.de

Wie sicher ist "Secure Keyboard Entry" im Mac OS X-Terminal?

Ich benutze Terminal seit Jahren unter Mac OS X, habe diese Funktion aber irgendwie übersehen:

Secure Keyboard Entry in Terminal

Ich frage mich jetzt, wie das eigentlich funktioniert und ist es 100% sicher? Wenn nicht, welche Technik könnte verwendet werden, um die Tastenanschläge noch zu erhalten?

39
Ivan Kovacevic

"Secure Keyboard Entry" ist der Funktion EnableSecureEventInput zugeordnet, deren Konzept beschrieben wird hier . Grundsätzlich greifen Anwendungen nicht auf die Hardware selbst zu. Sie erhalten Ereignisse (z. B. über Tastenanschläge) vom Betriebssystem. Einige Elemente im Betriebssystem entscheiden, welche Anwendung welche Ereignisse erhält, abhängig von ihren Zugriffsrechten und dem GUI-Status (es gibt Details, je nachdem, welche Anwendung "im Vordergrund" steht).

Anwendungen können sich gegenseitig "ausspionieren", was bedeutet (in diesem Fall), dass eine auf dem Computer ausgeführte Anwendung das Betriebssystem auffordern kann, ihm eine Kopie aller Tastenanschläge zu senden, auch wenn sie für eine andere Anwendung bestimmt sind, und/oder zu injizieren eigene synthetische Ereignisse. Dies ist eine Funktion: Sie ermöglicht Dinge wie "Passwort-Wallets" (die ein Passwort eingeben, als ob es vom Benutzer aus Sicht der Anwendung eingegeben worden wäre) oder den "Keyboard Viewer" "(die GUI-basierte Tastatur, mit der Sie Zeichen mit der Maus" eingeben "können und die auch anzeigt, welche Tasten zu einem bestimmten Zeitpunkt tatsächlich gedrückt werden). EnableSecureEventInput blockiert diese Funktion für die Anwendung, die sie aufruft. Versuch es ! Führen Sie Terminal.app aus, aktivieren Sie den "Keyboard Viewer" und stellen Sie sicher, dass das Aktivieren von "Secure Keyboard Entry" den Keyboard Viewer daran hindert, seine Arbeit zu erledigen.

All diese Ereignisweiterleitungen werden in einem User-Space-Prozess ausgeführt, der als root ausgeführt wird. Dies hängt davon ab von der vom Kernel erzwungenen Prozesstrennung: Ein normaler Benutzerprozess kann nicht nach Belieben mit dem für einen Root-Prozess zugewiesenen Speicher herumspielen. Der Kernel selbst kennt das Konzept "Ereignis" auf Benutzerebene nicht. Die Verwaltung von Ereignissen, insbesondere die Durchsetzung (oder nicht) von EnableSecureEventInput, erfolgt durch Nicht-Kernel-Code.

Ein interessanter Auszug der oben verlinkten Seite ist folgender:

Die ursprüngliche Implementierung von EnableSecureEventInput war so, dass Tastaturereignisse nicht an Intercept-Prozesse übergeben wurden, wenn ein Prozess die sichere Eingabe von Eingaben ermöglichte und den Tastaturfokus hatte. Wenn der sichere Eingabeprozess jedoch in den Hintergrund verschoben würde, würde das System weiterhin Tastaturereignisse an diese Abfangprozesse übergeben, da der Tastaturfokus nicht mehr auf einem sicheren Eingabeprozess lag.

Kürzlich wurde eine Sicherheitslücke gefunden, die es einem Abfangprozess ermöglichte, Tastaturereignisse zu erfassen, selbst in Fällen, in denen die Eingabe sicherer Ereignisse aktiviert war und der Prozess zur Eingabe sicherer Ereignisse im Hintergrund war. Die Lösung für dieses Problem besteht darin, die Übergabe von Tastaturereignissen an einen Abfangprozess zu beenden, wenn ein Prozess die sichere Ereigniseingabe aktiviert hat, unabhängig davon, ob sich dieser Prozess im Vordergrund oder im Hintergrund befindet. Dies bedeutet, dass ein Prozess, der die sichere Ereigniseingabe aktiviert und die sichere Ereigniseingabe für die Dauer des Programms aktiviert lässt, alle Tastaturabfangprozesse beeinflussen kann, selbst wenn der sichere Ereignisprozess in den Hintergrund verschoben wurde.

Dies bedeutet, dass das Ereignis-Routing-System in der ersten Rate der Funktion tatsächlich einen Fehler gemacht hat. Dies soll nun behoben werden.

Selbst wenn angenommen wird, dass das Ereignisrouting jetzt korrekt und sicher ist, was bedeutet, dass die Semantik von EnableSecureEventInput wirklich erzwungen wird, müssen Sie verstehen, dass dies der Fall ist vollständig relativ zum Prozesstrennsystem. Jeder Root-Prozess kann den Speicher aller anderen Prozesse nach Belieben überprüfen und ändern und insbesondere alle Ereignisse anzeigen. Ein Root-Prozess kann sich auch in den Kernel einhängen und die tatsächlichen Daten von der Tastatur überprüfen, wobei der Begriff des Ereignisses vollständig umgangen wird. Ein Key Logger, der als Root installiert werden kann, erledigt genau das, und "Secure Keyboard Entry" ist dagegen schutzlos. Siehe this für einen OpenSource-Proof of Concept.

"Secure Keyboard Entry" ist also nur gegen Angreifer sicher, die eigenen Code auf dem Computer ausführen können, ihre lokalen Berechtigungen jedoch nicht auf Root-Ebene eskalieren können. Dies ist ein eher restriktives Szenario, da eine Eskalation lokaler Berechtigungen im Allgemeinen möglich ist:

  • Der lokale Prozess kann einen Großteil der Maschine sehen, daher ist der zu verteidigende "Sicherheitsbereich" in diesem Fall sehr groß. Das Verhindern des Eindringens von remote Angreifern ist viel einfacher und doch schon ziemlich schwierig.

  • Apple neigt dazu, einige mangelnde Reaktivität im Fall von Eskalationslücken für lokale Privilegien aufzuweisen.


Zusammenfassung: Ich würde es als zu optimistisch empfinden, zu glauben, dass "Secure Keyboard Entry" eine ausreichende Sicherheit gegen Key Logger auf beispielsweise öffentlichen freigegebenen Computern bietet. Es ist keine schlechte Funktion, aber es erfüllt seine Versprechen nur, wenn root und der Kernel frei von böswilligen Änderungen sind, und das ist ein sehr großes "Wenn".

58
Tom Leek

Es gibt noch etwas, das es wert ist, beachtet zu werden - und es scheint mir nicht allgemein anerkannt zu sein: Auf POSIX-Systemen verfügt jedes Terminal über ein eigenes "Teletyp" -Gerät. Und jeder Prozess, den Sie ausführen, kann von diesem Gerät aus lesen , unabhängig davon, ob Sie "Secure Keyboard Entry" aktivieren (Linus Åkesson gibt eine Zusammenfassung von wie Unix-Systeme mit Endgeräten umgehen .)

Die Namen und Berechtigungen für solche Geräte variieren systemübergreifend. macOS nennt sie ab Version 10.14 tty[p-w][0-f]{1,3} und gewährt dem Benutzer, der das Terminal ausführt, Lese-/Schreibzugriff (und Nur-Schreibzugriff auf Mitglieder der Gruppe tty).

Sie können dies selbst versuchen, indem Sie "Secure Keyboard Entry" in iTerm.app aktivieren und tty aufrufen, um das Endgerät anzuzeigen Es verwendet und öffnet dann beispielsweise Terminal.app und liest von diesem Gerät mit cat. Sie werden feststellen, dass iTerm.app einige Zeichen empfängt und Terminal.app Andere.

(iTerm.appTerminal.app

1
Odin Kroeger