abraxas/sqlite-cli-recoverSQLite 3.53.4 CLI - Alta - Local - Inyección de comandos - recover dump emite un esquema hostil como comando de punto
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sqlite-cli-recover
Análisis: https://abraxaslabs.tech/research/sqlite-cli-recover
Clase: Inyección de comandos Alcance: Local
La CLI de SQLite 3.53.4 (b09c88c) .recover imprime un sqlite_schema.sql hostil como un dot-command posterior. recoverOneStmt prepara solo la primera sentencia. Un CREATE TABLE plantado más un .shell en una nueva línea se sigue escribiendo. La tubería de restauración documentada lo ejecuta con el UID del operador.
.dump printSchemaLine pertenece a la misma clase de emisión. No es libsqlite3. No es --safe. El oráculo es el echo de una cadena testigo.
| ID | aún sin CVE |
| Clase | Inyección de comandos (emisión de esquema de la CLI .recover / .dump) |
| Alcance | Local (la víctima ejecuta la tubería de recuperación documentada; UI:R) |
| CWE | CWE-78 |
| CVSS | Alta: 7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
| Producto | SQLite (CLI sqlite3) |
| Afectado | 3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) SOURCE_ID 2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc |
| Autenticación | la víctima ejecuta sqlite3 hostile.db .recover | sqlite3 restored.db |
| Licencia | GNU Affero GPL v3.0 |
| Laboratorio | solo 127.0.0.1:18930. Testigo SQLITE-CLI-RECOVER-WITNESS. |
Plantar un primer CREATE válido más un .shell posterior en sqlite_schema.sql. Una víctima que recupera esa base de datos en un segundo sqlite3 ejecuta el dot-command con su UID.
Lo plantado es un archivo .db. La acción de la víctima es la tubería de recuperación documentada, no una línea go pegada ni un --safe desactivado por accidente. .shell es system(). El oráculo del laboratorio es el echo de un testigo. No es una reverse shell.
Veinte búsquedas en el código fuente de 3.53.4. La propia búsqueda de recover calificó a recoverOneStmt como una preparación de solo la primera sentencia y siguió adelante. Lo que queda es la ruta de impresión: recoverSqlCb sigue emitiendo el texto adicional. Canalizar ese script es como sqlite.org te indica que restaures.
Errores ya registrados: tratar la preparación de la primera sentencia como un saneamiento; fijar la versión 3.54.0 (borrador); volver a presentar CVE-2022-46908 --safe; llamar a esto RCE de libsqlite3; usar una reverse shell como oráculo.
cd lab
./run.sh
Compila sqlite-src-3530400 en sqlite3 con la recuperación predeterminada de la CLI de Unix (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema tras .dbconfig defensive off. Se plantó CREATE TABLE t(x); más un salto de línea .shell echo SQLITE-CLI-RECOVER-WITNESS. .recover imprimió .shell. Canalizado a un segundo sqlite3, se ejecutó. Enlaza a loopback.
SUCCESS sqlite-cli-recover how=recover-pipe-dot-shell recover-has-shell=yes restore-echo=yes SQLITE-CLI-RECOVER-WITNESS
No imprimir SQL de esquema que no sea una única sentencia. Dividir en el primer prepare, emitir solo esa sentencia, o rechazar la fila. Citar el CREATE ordinario de la forma en que el volcado de tabla virtual ya usa %q. Tratar una línea . posterior como hostil y descartarla. --safe en el sqlite3 de restauración bloquea .shell; no está activado en la tubería documentada.
b09c88c14082339b66c7b7158d609a771e64ca69).recover documentado y luego restauraciónext/recover/sqlite3recover.c recoverOneStmt / recoverWriteSchema1src/shell.c.in recoverSqlCb, .dump printSchemaLine