Mercury: Nicht authentifizierte Remote-Code-Ausführung über /api/kernels

Mercury betreibt standardmäßig einen JupyterLab-Server mit anonymem Zugriff (mercury_app/__main__.py setzt --IdentityProvider.token='', wenn kein --token/MERCURY_TOKEN angegeben ist; ohne Token wird zudem --ServerApp.disable_check_xsrf=True gesetzt). Es stützt sich auf eine Blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files), um anonyme Benutzer von gefährlichen Jupyter-Endpunkten fernzuhalten.

Die Schwachstelle

/api/kernels ist NICHT in der Blocklist enthalten (und kann es auch nicht sein — Mercury benötigt Kernel zum Ausführen von Notebooks), und patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) überwacht lediglich das Idle-Timeout: Es kapselt on_message, um self.application._timeout_manager.touch() aufzurufen, und führt anschließend den ursprünglichen Handler ohne Filterung von execute_request aus. Jeder nicht authentifizierte Netzwerk-Client kann daher:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Unterschied zu GHSA-f8c7-rwf9-fmgm (unvollständige Behebung)

GHSA-f8c7 war „Unauthenticated RCE via /api/terminals“ — eine Blocklist-Umgehung aufgrund eines fehlenden Kommas. Dessen Behebung (Hinzufügen des Kommas, sodass /api/terminals blockiert wird) behebt /api/kernels NICHT, welcher weiterhin ausnutzbar bleibt. Der Blocklist-Ansatz ist prinzipiell nicht in der Lage, Kernel abzudecken; daher handelt es sich nicht um eine Variante, die durch einen weiteren Blocklist-Eintrag behoben werden kann.

Laufzeit-Nachweis (auf der gepatchten Version)

Unter mercury 3.2.4 — der Version, die GHSA-f8c7 behoben hat — mit der Standardkonfiguration (ohne Token) als nicht authentifizierter Client: POST /api/terminals liefert 403 zurück (der Fix für f8c7 ist vorhanden), aber POST /api/kernels liefert 201 zurück; das Öffnen des Kernel-Websockets und das Senden einer execute_request führte von Angreifern bereitgestellten Python-Code aus (führte whoami als Benutzer des Serverprozesses aus und schrieb die Marker-Datei /tmp/PWNED_MERCURY_RCE). Vollständige nicht authentifizierte Remote-Code-Ausführung. Deterministischer PoC (Client-Skript + Notebook) enthalten.

Auswirkungen

Nicht authentifizierte, netzwerkweit erreichbare Ausführung von beliebigem Code als Benutzer des Mercury-Serverprozesses auf jeder Standardinstallation — vollständige Kompromittierung des Hosts/Containers sowie sämtlicher erreichbarer Daten und Secrets.

Deduplizierung (3-Methode)

OSV.dev CLEAN(0) für mercury und mljar-mercury; das einzige Advisory des Repositorys (GHSA-f8c7-rwf9-fmgm) behandelt ausschließlich /api/terminals (die Beschreibung erwähnt keine Kernel); kein Issue/PR beschreibt die /api/kernels-RCE (#219/#134/#262 sind Feature-Requests zur Authentifizierung, die lediglich den standardmäßig anonymen Zugriff bestätigen). Die Schwachstelle wurde unabhängig auf dem aktuellen HEAD bestätigt (die Blocklist lässt /api/kernels aus; token='' als Standard; patch_kernel_websocket_handler führt keine Filterung von Ausführungen durch).

Finder: Abdullah Kareem (GitHub: CyberKareem).