abraxas/sqlite-cli-recoverSQLite 3.53.4 CLI - Hoch - Lokal - Command Injection - recover dump gibt feindseliges Schema als Dot-Command aus
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sqlite-cli-recover
Write-up: https://abraxaslabs.tech/research/sqlite-cli-recover
Klasse: Command Injection Reichweite: Lokal
Die SQLite 3.53.4 (b09c88c) CLI .recover gibt feindliches sqlite_schema.sql als späteren Dot-Command aus. recoverOneStmt bereitet nur die erste Anweisung vor. Ein eingeschleustes CREATE TABLE plus Zeilenumbruch .shell wird dennoch geschrieben. Die dokumentierte Restore-Pipe führt es mit der UID des Operators aus.
.dump printSchemaLine gehört zur selben Emit-Klasse. Nicht libsqlite3. Nicht --safe. Das Oracle ist echo eines Witness-Strings.
| ID | noch keine CVE |
| Klasse | Command Injection (CLI .recover / .dump Schema-Emit) |
| Reichweite | Lokal (Opfer führt die dokumentierte Recover-Pipe aus; UI:R) |
| CWE | CWE-78 |
| CVSS | Hoch: 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
| Produkt | SQLite (sqlite3 CLI) |
| Betroffen | 3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) SOURCE_ID 2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc |
| Auth | Opfer führt sqlite3 hostile.db .recover | sqlite3 restored.db aus |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1:18930. Witness SQLITE-CLI-RECOVER-WITNESS. |
Ein gültiges erstes CREATE plus ein späteres .shell in sqlite_schema.sql einschleusen. Ein Opfer, das diese DB in eine zweite sqlite3 wiederherstellt, führt den Dot-Command mit seiner UID aus.
Die Einschleusung ist eine .db-Datei. Die Opferaktion ist die dokumentierte Recover-Pipe, keine eingefügte go-Zeile und kein versehentlich deaktiviertes --safe. .shell ist system(). Das Lab-Oracle ist echo eines Witness. Keine Reverse Shell.
Zwanzig Quellcode-Jagden auf 3.53.4. Die eigene Jagd von Recover nannte recoverOneStmt eine Prepare-Operation nur für die erste Anweisung und ging weiter. Der Rest ist der Print-Pfad: recoverSqlCb gibt den zusätzlichen Text weiterhin aus. Dieses Skript zu pipen ist die Art, wie sqlite.org Ihnen sagt, dass Sie wiederherstellen sollen.
Bereits festgehaltene Irrwege: das Prepare der ersten Anweisung als Strip zu behandeln; auf 3.54.0 (Entwurf) zu pinnen; CVE-2022-46908 --safe erneut einzureichen; dies als libsqlite3-RCE zu bezeichnen; eine Reverse Shell als Oracle zu verwenden.
cd lab
./run.sh
Baut sqlite-src-3530400 zu sqlite3 mit standardmäßigem Unix-CLI-Recover (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema nach .dbconfig defensive off. Eingeschleustes CREATE TABLE t(x); plus Zeilenumbruch .shell echo SQLITE-CLI-RECOVER-WITNESS. .recover gab .shell aus. In ein zweites sqlite3 gepipet, wurde es ausgeführt. Bind Loopback.
SUCCESS sqlite-cli-recover how=recover-pipe-dot-shell recover-has-shell=yes restore-echo=yes SQLITE-CLI-RECOVER-WITNESS
Gibt kein Schema-SQL aus, das nicht aus einer einzigen Anweisung besteht. Teile beim ersten Prepare auf, gib nur diese Anweisung aus oder lehne die Zeile ab. Zitiere gewöhnliches CREATE so, wie es der Dump virtueller Tabellen bereits mit %q tut. Behandle eine spätere .-Zeile als feindlich und verwerfe sie. --safe beim Wiederherstellen von sqlite3 blockiert .shell; es ist in der dokumentierten Pipe nicht aktiv.
b09c88c14082339b66c7b7158d609a771e64ca69).recover und anschließendes Wiederherstellenext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1src/shell.c.in recoverSqlCb, .dump printSchemaLine