abraxas/sqlite-cli-recoverSQLite 3.53.4 CLI — High — Локальная — Инъекция команд — recover dump выводит враждебную схему как dot-команду
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sqlite-cli-recover
Разбор: https://abraxaslabs.tech/research/sqlite-cli-recover
Класс: Внедрение команд Доступ: Локальный
CLI-команда .recover в SQLite 3.53.4 (b09c88c) выводит враждебный sqlite_schema.sql как последующую dot-команду. recoverOneStmt подготавливает только первый оператор. Внедрённый CREATE TABLE вместе с переводом строки и .shell всё равно записывается. Документированный конвейер восстановления выполняет его с UID оператора.
printSchemaLine в .dump относится к тому же классу вывода. Это не libsqlite3. Это не --safe. Оракулом служит echo строки-свидетеля.
| ID | CVE пока нет |
| Класс | Внедрение команд (вывод схемы в CLI .recover / .dump) |
| Доступ | Локальный (жертва запускает документированный конвейер восстановления; 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 |
| Продукт | SQLite (CLI sqlite3) |
| Затронуто | 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. Свидетель SQLITE-CLI-RECOVER-WITNESS. |
Внедрить корректный первый CREATE вместе с последующим .shell в sqlite_schema.sql. Жертва, которая восстанавливает эту БД во второй sqlite3, выполняет dot-команду со своим UID.
Внедрение — это файл .db. Действие жертвы — документированный конвейер восстановления, а не вставленная строка go и не случайно отключённый --safe. .shell — это system(). Оракул в лаборатории — echo свидетеля. Не reverse shell.
Двадцать поисков по исходникам 3.53.4. Собственный поиск в recover назвал recoverOneStmt подготовкой только первого оператора и на этом остановился. Остаток — это путь вывода: recoverSqlCb всё равно выводит лишний текст. Передача этого скрипта через конвейер — это то, как sqlite.org советует восстанавливать.
Уже зафиксированные ошибочные пути: трактовка подготовки первого оператора как очистки; привязка к 3.54.0 (черновик); повторная подача CVE-2022-46908 --safe; называние этого RCE в libsqlite3; использование reverse shell в качестве оракула.
cd lab
./run.sh
Собирает sqlite-src-3530400 в sqlite3 со стандартным Unix CLI recover (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema после .dbconfig defensive off. Внедрён CREATE TABLE t(x); плюс перевод строки .shell echo SQLITE-CLI-RECOVER-WITNESS. .recover вывел .shell. При передаче через конвейер во второй sqlite3 он выполнился. Привязка к loopback.
SUCCESS sqlite-cli-recover how=recover-pipe-dot-shell recover-has-shell=yes restore-echo=yes SQLITE-CLI-RECOVER-WITNESS
Не выводите SQL-код схемы, если он не является единственным оператором. Разделяйте по первому prepare, выводите только этот оператор или отказывайтесь от строки. Заключайте обычный CREATE в кавычки так же, как это уже делает дамп виртуальных таблиц с помощью %q. Рассматривайте последующую строку с . как враждебную и отбрасывайте её. --safe в restore sqlite3 блокирует .shell; в документированном конвейере он не включён.
b09c88c14082339b66c7b7158d609a771e64ca69).recover с последующим восстановлениемext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1src/shell.c.in recoverSqlCb, .dump printSchemaLine