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

लेख: https://abraxaslabs.tech/research/sqlite-cli-recover

sqlite-cli-recover

वर्ग: कमांड इंजेक्शन पहुँच: स्थानीय

SQLite 3.53.4 (b09c88c) CLI .recover शत्रुतापूर्ण sqlite_schema.sql को बाद के dot-command के रूप में प्रिंट करता है। recoverOneStmt केवल पहले स्टेटमेंट को तैयार करता है। एक रोपित CREATE TABLE और न्यूलाइन .shell फिर भी लिखा जाता है। प्रलेखित restore पाइप इसे ऑपरेटर UID के रूप में चलाता है।

.dump का printSchemaLine वही emit वर्ग है। libsqlite3 नहीं। --safe नहीं। Oracle एक witness स्ट्रिंग का echo है।

ID	अभी तक कोई CVE नहीं
वर्ग	कमांड इंजेक्शन (CLI .recover / .dump schema emit)
पहुँच	स्थानीय (पीड़ित प्रलेखित recover पाइप चलाता है; UI:R)
CWE	CWE-78
CVSS	उच्च: 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
उत्पाद	SQLite (sqlite3 CLI)
प्रभावित	3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) SOURCE_ID 2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc
प्रमाणीकरण	पीड़ित sqlite3 hostile.db .recover | sqlite3 restored.db चलाता है
लाइसेंस	GNU Affero GPL v3.0
लैब	केवल 127.0.0.1:18930। Witness SQLITE-CLI-RECOVER-WITNESS।

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

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

रोपण एक .db फ़ाइल है। पीड़ित की क्रिया प्रलेखित recover पाइप है, न कि पेस्ट की गई go लाइन और न ही गलती से बंद किया गया --safe। .shell यानी system()। लैब oracle एक witness का echo है। रिवर्स शेल नहीं।

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

3.53.4 की बीस स्रोत खोजें। Recover की अपनी खोज ने recoverOneStmt को केवल-पहला-स्टेटमेंट prepare कहकर छोड़ दिया। बचा हुआ हिस्सा प्रिंट पथ है: recoverSqlCb अतिरिक्त टेक्स्ट फिर भी उत्सर्जित करता है। उस स्क्रिप्ट को पाइप करना ही वह तरीका है जो sqlite.org आपको restore के लिए बताता है।

पहले से दर्ज गलत मोड़: पहला-स्टेटमेंट prepare को strip मानना; 3.54.0 (ड्राफ्ट) को पिन करना; CVE-2022-46908 --safe को फिर से दायर करना; इसे libsqlite3 RCE कहना; oracle के रूप में रिवर्स शेल का उपयोग करना।

लैब

cd lab
./run.sh

sqlite-src-3530400 को sqlite3 में डिफ़ॉल्ट Unix CLI recover (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB) के साथ बनाता है। .dbconfig defensive off के बाद writable_schema। CREATE TABLE t(x); के साथ-साथ नई पंक्ति .shell echo SQLITE-CLI-RECOVER-WITNESS रखा गया। .recover ने .shell प्रिंट किया। दूसरे sqlite3 में पाइप किए जाने पर, यह चल गया। लूपबैक बाइंड करें।

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

समाधान

ऐसा schema SQL मत प्रिंट करें जो एकल कथन न हो। पहले prepare पर विभाजित करें, केवल उसी कथन को उत्सर्जित करें, या पंक्ति को अस्वीकार करें। सामान्य CREATE को उसी तरह उद्धृत करें जैसे virtual-table dump पहले से %q का उपयोग करता है। बाद की . पंक्ति को शत्रुतापूर्ण मानें और उसे हटा दें। restore sqlite3 पर --safe .shell को अवरुद्ध करता है; यह प्रलेखित pipe में सक्षम नहीं है।

संदर्भ

• sqlite.org/src टैग version-3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69)
• Recovering Data From A Corrupt SQLite Database - प्रलेखित .recover फिर restore
• ext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1
• src/shell.c.in recoverSqlCb, .dump printSchemaLine