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
Write-up : https://abraxaslabs.tech/research/sqlite-cli-recover
Classe : Injection de commande Portée : Locale
La commande .recover de la CLI SQLite 3.53.4 (b09c88c) affiche un sqlite_schema.sql hostile sous forme de 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.
printSchemaLine de .dump relève de la même classe d'émission. Ce n'est pas libsqlite3. Ce n'est 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 par la 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 propre 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 un --safe désactivé par accident. .shell correspond à system(). L'oracle du lab est un echo d'un témoin. Pas un reverse shell.
Vingt chasses dans le code source de 3.53.4. La chasse propre à recover a qualifié recoverOneStmt de préparation limitée à la première instruction et est passée à autre chose. Le reliquat est le chemin d'impression : recoverSqlCb émet toujours le texte supplémentaire. C'est en pipant ce script que sqlite.org vous indique de restaurer.
Fausses pistes déjà consignées : considérer la préparation de la première instruction comme un nettoyage ; épingler 3.54.0 (brouillon) ; redé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 la récupération CLI Unix par défaut (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema après .dbconfig defensive off. Injection de CREATE TABLE t(x); suivi d'un saut de ligne .shell echo SQLITE-CLI-RECOVER-WITNESS. .recover a affiché .shell. Redirigé via un pipe vers un second sqlite3, il s'est exécuté. Liaison sur 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 au premier prepare, n'émettre que cette instruction, ou refuser la ligne. Citer le CREATE ordinaire de la manière dont le dump de table virtuelle utilise déjà %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