Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
spark-python-ds-static — Apache Spark 4.2.0 - Hoch - Remote - Privilegien-Reste - prozessglobale Python-Datenquellen-Zuordnung | Kitploit
Tools/GitHubGitHub/abraxas/spark-python-ds-static
Privilege EscalationSchwachstellenanalyseExploitationPost-ExploitationPapers & ForschungRed TeamingPayload-EntwicklungLabs & Praxis
GitHubabraxas/spark-python-ds-static

spark-python-ds-static

Apache Spark 4.2.0 - Hoch - Remote - Privilegien-Reste - prozessglobale Python-Datenquellen-Zuordnung

Repository anzeigen
vor 2 TagenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Abraxas Labs - spark-python-ds-static

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  spark-python-ds-static

spark-python-ds-static

Klasse: Privilegien-Überrest Reichweite: Remote

Apache Spark 4.2.0 (32f72996) - Apache Software Foundation

DataSourceManager.dataSourceBuilders ist eine JVM-globale First-Wins-Map. SPARK-45917 registriert pyspark_* Python Data Sources automatisch aus dem sys.path des Lookup-Workers. Die Connect-Session-Isolierung hält Artefakte unter SparkFiles/<sessionUUID>/, und das sitzungsbezogene registerPython bleibt auf runtimeDataSourceBuilders. Der erste Lookup legt dennoch das SparkFiles-Verzeichnis der auslösenden Session auf sys.path, pickelt jedes DefaultSource und cached diese Klassen im Companion-Objekt. Späteres Connect-SQL (oder Hive-Thrift-SQL) read.format(name) / USING name führt diese Klasse als Spark-UID aus, ohne Python-Proto zu senden.

Der Pflanzer ist ein Connect-Python-Mandant, dem Python bereits erlaubt ist. Das Opfer ist ein reiner SQL-Mandant auf demselben Connect-Treiber. Java-Aliase (parquet, csv, json, orc, jdbc) bleiben auf dem Java-ServiceLoader-Pfad. Spätere Pflanzungen, nachdem die Map gefüllt ist, aktualisieren nicht. AC:H ist First-Lookup plus ein Name, der kein Java-Alias ist.

IDnoch keine CVE
KlassePrivilegien-Überrest (Cross-Session Python Data Source als Spark-UID; kein Unauth-Job-Submit)
ReichweiteRemote (gemeinsamer Spark-Connect-Treiber)
CWECWE-269, CWE-502
CVSSHigh: 8.8 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
ProduktApache Spark
Betroffen4.2.0 (32f7299601108917fb01920a54e084595b7b3bf8) Python Data Source Static Registry
AuthConnect-Python-Mandant (Pflanzer) plus ein späterer reiner SQL-Connect-/Hive-Thrift-SQL-Benutzer (Opfer)
LizenzGNU Affero GPL v3.0
Labnur 127.0.0.1:18970. Witness-Datei. Gadget der Companion-Map.

Was ein Angreifer tun kann

Eine Spark-Connect-Python-Session auf einem gemeinsamen Treiber halten. pyfiles/pyspark_<name>.py pflanzen, dessen DefaultSource.name() ein nicht vorhandener Connector-Kurzname ist (delta, iceberg, hudi, ...). Den ersten Python-Data-Source-Lookup in dieser Session auslösen. Jede spätere Session in derselben JVM, die read.format(name) oder SQL USING name ausführt, instanziiert die gepickelte Klasse als Spark-UID im Driver-Planner-Worker und auf den Executors.

Das ist die vollständige Privilegienmenge. Der Pflanzer führt bereits Python aus. Der Überrest besteht darin, dass ein reiner SQL-Mandant, der nie REGISTER_DATA_SOURCE / Python-UDF-Proto gesendet hat, diese Klasse dennoch ausführt.

Integrität (lab-bestätigt)

MethodeSinkPrivileg
Pflanzer: AddArtifacts Name pyfiles/pyspark_<name>.py, dann erstes format(name) / LookupCompanion DataSourceManager.dataSourceBuilders (DataSourceManager.scala-Objekt) plus lookup_data_sources.py iter_modules von pyspark_*Das gepickelte DefaultSource der auslösenden Session JVM-weit cachen. Lab: layer='static' trigger='attacker' first-wins=yes.
Opfer: SQL USING <name> / spark.read.format(name) in einer Session, die nie gepflanzt hatPythonDataSourceV2 createDataSourceInPythonDiese Klasse als Spark-UID ausführen. Lab: planted_by='attacker' witness_written=True static-cross-session=yes. Oracle-Datei enthält SPARK-PYTHON-DS-STATIC-WITNESS.

Geschlossen in diesem Durchlauf (lab-bestätigt)

MethodeSinkErgebnis
Spätere Pflanzung eines zweiten Namens, nachdem die Map gefüllt istdieselbe statische MapGeschlossen. First-Wins. Lab: later-lookup found=False, Companion weiterhin nur delta.
Sitzungsbezogenes registerPython("alpha")runtimeDataSourceBuildersIsoliert. Clone kopiert nur Runtime. Lab: runtime-isolated=yes. Opfer-Lesen von alpha ist found=False.
Java-Alias parquetJava DataSourceRegister ServiceLoaderGeschlossen. Lab: java-alias-closed=yes layer='java'. Dasselbe für csv/json/orc/jdbc.

Abgeleitet (dieselben Sinks, nicht das Oracle)

MethodeSinkPrivileg
Opfer USING nach PflanzungDriver- + Executor-Python-WorkerCluster-weiter Code als Spark-UID. Das Lab schreibt eine Witness-Datei statt einer Payload.
Derselbe PfadWorker-Absturz / SpinVerfügbarkeit als Spark-UID. Nicht das High. Das High ist die Codeausführung.
Hive-Thrift-SQL USING auf einer gemeinsamen SparkSessiondieselbe statische MapDerselbe Überrest, wenn Thrift und Connect dieselbe Driver-JVM teilen. Nicht getestet.

Was dieser Überrest nicht gewährt

  • Unauthentifiziertes Job-Submit auf einem offenen Cluster. SECURITY.md FAQ. By Design.
  • Java-parquet / csv / json / orc / jdbc-Hijack. ServiceLoader gewinnt.
  • Artefakt-Pfad-Escape (concatenatePaths lehnt .. und absolute Namen ab).
  • Client-seitig geliefertes pythonExec. Connect-Planner verwendet Server-PYSPARK_PYTHON / python3.
  • Cross-Session-Leak von registerPython. Runtime-Map ist pro DataSourceManager-Instanz.
  • Einzelbenutzer-lokales pyspark mit einer Session. Es gibt keinen anderen Mandanten.
  • Ein Miss-First-Lookup, der eine leere Map füllt. Spätere Pflanzungen aktualisieren nicht (AC:H).

Wie ich es gefunden habe

Ich habe apache/spark v4.2.0 (32f7299601108917fb01920a54e084595b7b3bf8) gepinnt. Achtundzwanzig Source-Hunts. Job-Submit, der Benutzercode ausführt, ist by Design. History Jackson, UI-Shell, PySpark-lokale Impersonation und der Standalone-RPC-Receive-Path sind in diesem Peel geschlossen. Connect-Artefakte isolieren pyfiles unter einer Session-UUID. Runtime-registerPython ist pro Session. Das Companion-Objekt nicht.

SPARK-45917 registriert pyspark_*-Pakete automatisch aus PYTHONPATH. Das ist für operator-installierte Connectoren gedacht. Der Überrest besteht darin, dass der Lookup-Worker außerdem das SparkFiles-Verzeichnis der auslösenden Session per sys.path.insert einfügt (worker_util.setup_spark_files) und dann jedes gefundene pyspark_* DefaultSource in eine prozessglobale Map pickelt, die nie aktualisiert wird.

Fehlweg: die registerPython-Isolierung als die gesamte Mandantenschranke zu betrachten. Runtime ist isoliert. Static nicht.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:18970. Compose-Projekt spark-python-ds-static. Witness SPARK-PYTHON-DS-STATIC-WITNESS. Python-Gadget von object DataSourceManager plus sitzungsbezogene Runtime-Maps. pyspark_delta.py nur in den SparkFiles des Angreifers pflanzen. Angreifer-Lookup füllt den Companion. Spätere Pflanzung von iceberg aktualisiert nicht. Opfer-read von delta schreibt das Oracle. registerPython("alpha") leakt nicht. Java-parquet bleibt Java.

Letzte Zeile:

SUCCESS SPARK-PYTHON-DS-STATIC static-cross-session=yes runtime-isolated=yes first-wins=yes java-alias-closed=yes SPARK-PYTHON-DS-STATIC-WITNESS

Der Fix

Tool herunterladen