←back to thread

What If OpenDocument Used SQLite?

(www.sqlite.org)
275 points whatisabcdefgh | 2 comments | 04 Sep 25 21:36 UTC | HN request time: 0.406s | source
Show context
agwa ◴[05 Sep 25 01:06 UTC] No.45134010[source]▶
If you're going to use SQLite as an application file format, you should:

1. Enable the secure_delete pragma <https://antonz.org/sqlite-secure-delete/> so that when your user deletes something, the data is actually erased. Otherwise, when a user shares one of your application's files with someone else, the recipient could recover information that the sender thought they had deleted.

2. Enable the options described at <https://www.sqlite.org/security.html#untrusted_sqlite_databa...> under "Untrusted SQLite Database Files" to make it safer to open files from untrusted sources. No one wants to get pwned when they open an email attachment.

3. Be aware that when it comes to handling security vulnerabilities, the SQLite developers consider this use case to be niche ("few real-world applications" open SQLite database files from untrusted sources, they say) and they seem to get annoyed that people run fuzzers against SQLite, even though application file formats should definitely be fuzzed. https://www.sqlite.org/cves.html

They fail to mention any of this on their marketing pages about how you should use SQLite as an application file format.

replies(5): >>45134731 #>>45134835 #>>45135122 #>>45139562 #>>45141557 #
chris_wot ◴[05 Sep 25 03:26 UTC] No.45134731[source]▶
"Most applications can use SQLite without having to worry about bugs in obscure SQL inputs." And then they recommend SQLite as a document interchange format.
replies(2): >>45135429 #>>45136586 #
1. ncruces ◴[05 Sep 25 09:18 UTC] No.45136586[source]▶
Untrusted database file is not the same as untrusted SQL input.

There are parts of the SQL engine that are exposed to malicious file manipulation (the schema is stored as SQL DDL text) but that's not arbitrary SQL input.

If you want to highlight an inconsistency, this is way more worrying:

> “All historical vulnerabilities reported against SQLite require at least one of these preconditions: (…) 2. The attacker can submit a maliciously crafted database file to the application that the application will then open and query. Few real-world applications meet either of these preconditions…”

However, most of the rest of the page is speaking of arbitrary SQL input, not purposely broken database files.

replies(1): >>45138078 #
2. agwa ◴[05 Sep 25 13:05 UTC] No.45138078[source]▶
> There are parts of the SQL engine that are exposed to malicious file manipulation (the schema is stored as SQL DDL text) but that's not arbitrary SQL input.

View and triggers can contain arbitrary SQL and can be defined by a malicious database file, though these can be disabled as described on the "Defense Against The Dark Arts" page.

That leaves default column values and indexes on expressions, which can execute a limited subset of SQL. I'd be worried about certain arbitrary SQL input vulnerabilities being reachable this way.