Hacker News Reader

Comment by indigo945 | Hacker News Reader

While this makes things easy, you should not do this for any application file format where you except your users to share files. This is because opening a SQLite database file makes the SQLite library execute any arbitrary code that may be stored in that file. [0] Therefore, SQLite is really only suitable for local-only file formats, such as configuration files, and not for files that users will e-mail to each other.

[0] https://media.ccc.de/v/36c3-10701-select_code_execution_from...

View on HN

This is misinformation. SQLite does not execute arbitrary code found in the data file. There was a bug, long since fixed, that could be used by an attacker to cause arbitrary code execution upon opening the database file. The referenced video talks about it. It was a very clever attack. But the bug that enabled the attack was fixed even before the talk shown in the video was given.

Let me say that again: SQLite does NOT execute arbitrary code that it finds in the database file. To suggestion that it does is nonsense.

See https://www.sqlite.org/security.html for additional discussion of security precautions you can take when using SQLite with potentially hostile files. The latest SQLite's should be safe right out of the box, without having to do anything mentioned on that page. But defense in depth never hurts.

Are custom FTS3 tokenizers disabled by default on current SQLite versions? The documentation does not mention it (and also doesn't warn of the security concern around enabling them). Otherwise, I do not see how the attack vector discussed in the video could be "fixed". The security guideline recommends disabling triggers and views, which is also a logical remedy, but seems brittle, nevermind also impractical for a wide range of applications.

The documentation on the fts3_tokenizer function merely states that

    Prior to SQLite version 3.11.0 (2016-02-15), the
     arguments to fts3_tokenzer() could be 
     literal strings or BLOBs. They did not have to be bound
     parameters. But that could lead to security 
     problems in the event of an SQL injection. Hence, the
      legacy behavior is now disabled by default.

However, it does not discuss any mitigations for the case where SQL injections are not needed, because the attacker controls the database file.

See https://www.sqlite.org/fts3.html#custom_application_defined_...

Since 2016, arguments to the fts3_tokenizer() function must be variables (ex: ? or :var or @var or $var) to which values are supplied by the application at run-time using sqlite3_bind_pointer(). There is no way to do this from pure SQL script. Nor is there any way to do this from within a view or trigger. There is no way to invoke fts3_tokenizer() from a maliciously corrupted schema or database.

Weren't all of these issues quickly fixed by the developers after being reported?

E: oh whoops missed the dev post above mine

Thanks for the heads-up!

In my use case, files are shared between different instances of the application, usually without user intervention, but there's an attack vector to be addressed here.

Reply on news.ycombinator.com