abraxas/sqlite-cli-recoverSQLite 3.53.4 CLI - Élevé - Local - Injection de commande - recover dump émet un schéma hostile en tant que dot-command
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sqlite-cli-recover
Classe : Injection de commande Portée : Locale
SQLite 3.53.4 (b09c88c) CLI .recover imprime un sqlite_schema.sql hostile comme une dot-commande ultérieure. recoverOneStmt ne prépare que la première instruction. Un CREATE TABLE planté suivi d'un .shell sur une nouvelle ligne est tout de même écrit. Le pipe de restauration documenté l'exécute avec l'UID de l'opérateur.
.dump printSchemaLine relève de la même classe d'émission. Pas libsqlite3. Pas --safe. L'oracle est un echo d'une chaîne témoin.
| ID | pas encore de CVE |
| Classe | Injection de commande (émission de schéma CLI .recover / .dump) |
| Portée | Locale (la victime exécute le pipe de restauration documenté ; UI:R) |
| CWE | CWE-78 |
| CVSS | Élevé : 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
| Produit | SQLite (CLI sqlite3) |
| Affecté | 3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) SOURCE_ID 2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc |
| Auth | la victime exécute sqlite3 hostile.db .recover | sqlite3 restored.db |
| Licence | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1:18930 uniquement. Témoin SQLITE-CLI-RECOVER-WITNESS. |
Plantez un premier CREATE valide suivi d'un .shell ultérieur dans sqlite_schema.sql. Une victime qui restaure cette base dans un second sqlite3 exécute la dot-commande avec son UID.
Le plant est un fichier .db. L'action de la victime est le pipe de restauration documenté, pas une ligne go collée et pas --safe désactivé par accident. .shell est system(). L'oracle du lab est un echo d'un témoin. Pas un reverse shell.
Vingt recherches dans les sources de 3.53.4. La recherche propre à recover a qualifié recoverOneStmt de préparation limitée à la première instruction et est passée à autre chose. Le résidu est le chemin d'impression : recoverSqlCb émet toujours le texte supplémentaire. Rediriger ce script est la façon dont sqlite.org vous dit de restaurer.
Fausses pistes déjà consignées : traiter la préparation de la première instruction comme un nettoyage ; épingler 3.54.0 (brouillon) ; re-déposer CVE-2022-46908 --safe ; qualifier ceci de RCE libsqlite3 ; utiliser un reverse shell comme oracle.
cd lab
./run.sh
Compile sqlite-src-3530400 en sqlite3 avec le recover CLI Unix par défaut (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema après .dbconfig defensive off. CREATE TABLE t(x); planté suivi d'un .shell echo SQLITE-CLI-RECOVER-WITNESS sur une nouvelle ligne. .recover a imprimé .shell. Redirigé dans un second sqlite3, il s'est exécuté. Bind loopback.
SUCCESS sqlite-cli-recover how=recover-pipe-dot-shell recover-has-shell=yes restore-echo=yes SQLITE-CLI-RECOVER-WITNESS
Ne pas imprimer de SQL de schéma qui ne soit pas une instruction unique. Découper sur la première préparation, n'émettre que cette instruction, ou refuser la ligne. Citer les CREATE ordinaires comme le fait déjà le dump de table virtuelle avec %q. Traiter une ligne . ultérieure comme hostile et la supprimer. --safe sur le sqlite3 de restauration bloque .shell ; il n'est pas activé dans le pipe documenté.
b09c88c14082339b66c7b7158d609a771e64ca69).recover documenté puis restaurationext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1src/shell.c.in recoverSqlCb, .dump printSchemaLine