abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  sqlite-cli-recover

sqlite-cli-recover

Class: Command injection Reach: Local

SQLite 3.53.4 (b09c88c) CLI .recover बाद के dot-command के रूप में hostile sqlite_schema.sql प्रिंट करता है। recoverOneStmt केवल पहले statement को prepare करता है। एक planted CREATE TABLE के साथ newline .shell अभी भी लिखा जाता है। documented restore pipe इसे operator UID के रूप में चलाता है।

.dump printSchemaLine वही emit class है। libsqlite3 नहीं। --safe नहीं। Oracle एक witness string का echo है।

ID	अभी तक कोई CVE नहीं
Class	Command injection (CLI .recover / .dump schema emit)
Reach	Local (victim documented recover pipe चलाता है; 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
Product	SQLite (sqlite3 CLI)
Affected	3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) SOURCE_ID 2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc
Auth	victim sqlite3 hostile.db .recover | sqlite3 restored.db चलाता है
License	GNU Affero GPL v3.0
Lab	केवल 127.0.0.1:18930। Witness SQLITE-CLI-RECOVER-WITNESS।

हमलावर क्या कर सकता है

sqlite_schema.sql में एक valid पहला CREATE और बाद में एक .shell plant करें। जो victim उस db को दूसरे sqlite3 में recover करता है, वह dot-command को अपने UID के रूप में चलाता है।

Plant एक .db फ़ाइल है। Victim action documented recover pipe है, न कि pasted go line और न ही गलती से --safe off। .shell system() है। Lab oracle एक witness का echo है। Reverse shell नहीं।

मैंने इसे कैसे खोजा

3.53.4 की बीस source hunts। Recover की अपनी hunt ने recoverOneStmt को first-statement-only prepare कहा और आगे बढ़ गई। बचा हुआ हिस्सा print path है: recoverSqlCb अभी भी अतिरिक्त text emit करता है। उस script को pipe करना ही वह तरीका है जो sqlite.org restore करने के लिए बताता है।

पहले से दर्ज गलत रास्ते: first-statement prepare को strip मानना; 3.54.0 (draft) pin करना; CVE-2022-46908 --safe को re-file करना; इसे libsqlite3 RCE कहना; oracle के रूप में reverse shell का उपयोग करना।

Lab

cd lab
./run.sh

sqlite-src-3530400 को default Unix CLI recover (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB) के साथ sqlite3 में build करता है। .dbconfig defensive off के बाद writable_schema। Planted CREATE TABLE t(x); के साथ newline .shell echo SQLITE-CLI-RECOVER-WITNESS। .recover ने .shell प्रिंट किया। दूसरे sqlite3 में pipe किया गया, तो यह चला। Bind loopback।

SUCCESS sqlite-cli-recover how=recover-pipe-dot-shell recover-has-shell=yes restore-echo=yes SQLITE-CLI-RECOVER-WITNESS

समाधान

ऐसा schema SQL प्रिंट न करें जो एक single statement न हो। पहले prepare पर split करें, केवल वही statement emit करें, या row को refuse करें। साधारण CREATE को उसी तरह quote करें जैसे virtual-table dump पहले से %q का उपयोग करता है। बाद की . line को hostile मानें और उसे drop करें। restore sqlite3 पर --safe .shell को block करता है; यह documented pipe में on नहीं है।

संदर्भ

• sqlite.org/src tag version-3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69)
• Recovering Data From A Corrupt SQLite Database - documented .recover फिर restore
• ext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1
• src/shell.c.in recoverSqlCb, .dump printSchemaLine