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
Clase: Inyección de comandos Alcance: Local
SQLite 3.53.4 (b09c88c) CLI .recover imprime sqlite_schema.sql hostil como un dot-command posterior. recoverOneStmt prepara solo la primera sentencia. Un CREATE TABLE plantado más una nueva línea .shell se sigue escribiendo. La tubería de restauración documentada lo ejecuta como el UID del operador.
.dump printSchemaLine es la misma clase de emisión. No es libsqlite3. No es --safe. El oráculo es echo de una cadena testigo.
| ID | sin CVE todavía |
| Clase | Inyección de comandos (emisión de esquema de CLI .recover / .dump) |
| Alcance | Local (la víctima ejecuta la tubería de recuperación documentada; UI:R) |
| CWE | CWE-78 |
| CVSS | Alto: 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 |
| Auth | la víctima ejecuta sqlite3 hostile.db .recover | sqlite3 restored.db |
| Licencia | GNU Affero GPL v3.0 |
| Lab | 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 db en un segundo sqlite3 ejecuta el dot-command como su UID.
El 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 y no --safe desactivado por accidente. .shell es system(). El oráculo del lab es 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 llamó a recoverOneStmt un prepare de solo primera sentencia y siguió de largo. El residuo es la ruta de impresión: recoverSqlCb sigue emitiendo el texto extra. Tuberizar ese script es como sqlite.org te dice que restaures.
Desvíos ya registrados: tratar el prepare de primera sentencia como un strip; fijar 3.54.0 (borrador); volver a reportar 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 el recover de CLI Unix por defecto (OPT_SHELL / SQLITE_ENABLE_DBPAGE_VTAB). writable_schema tras .dbconfig defensive off. Plantado CREATE TABLE t(x); más nueva línea .shell echo SQLITE-CLI-RECOVER-WITNESS. .recover imprimió .shell. Tuberizado en un segundo sqlite3, se ejecutó. Bind 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 como ya hace el dump de virtual-table con %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