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
Klasse: Command Injection Reichweite: Lokal
Die SQLite 3.53.4 (b09c88c) CLI .recover gibt feindliches sqlite_schema.sql als späteren Dot-Befehl 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 als Operator-UID aus.
.dump printSchemaLine ist dieselbe Emit-Klasse. Nicht libsqlite3. Nicht --safe. Orakel 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 | High: 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 ein zweites sqlite3 recovert, führt den Dot-Befehl als seine 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-Orakel ist echo eines Witness. Keine Reverse Shell.
Zwanzig Source-Hunts von 3.53.4. Recover's eigener Hunt nannte recoverOneStmt ein Prepare nur für die erste Anweisung und ging weiter. Der Rest ist der Print-Pfad: recoverSqlCb gibt den zusätzlichen Text dennoch aus. Dieses Skript zu pipen ist die Art, wie sqlite.org Ihnen sagt, dass Sie wiederherstellen sollen.
Bereits dokumentierte Irrwege: das First-Statement-Prepare als Strip zu behandeln; 3.54.0 (Entwurf) festzunageln; CVE-2022-46908 --safe erneut einzureichen; dies als libsqlite3-RCE zu bezeichnen; eine Reverse Shell als Orakel zu verwenden.
cd lab
./run.sh
Baut sqlite-src-3530400 zu sqlite3 mit Standard-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
Geben Sie kein Schema-SQL aus, das keine einzelne Anweisung ist. Teilen Sie beim ersten Prepare, geben Sie nur diese Anweisung aus, oder verweigern Sie die Zeile. Quoten Sie gewöhnliches CREATE so, wie der Virtual-Table-Dump bereits %q verwendet. Behandeln Sie eine spätere .-Zeile als feindlich und verwerfen Sie sie. --safe auf dem Restore-sqlite3 blockiert .shell; es ist in der dokumentierten Pipe nicht aktiv.
b09c88c14082339b66c7b7158d609a771e64ca69).recover dann Restoreext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1src/shell.c.in recoverSqlCb, .dump printSchemaLine