3 ms·

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 SQLit

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_using_sqlite https://media.ccc.de/v/36c3-10701-select_code_execution_from...

adamrezich 6y ago
Weren't all of these issues quickly fixed by the developers after being reported? E: oh whoops missed the dev post above mine
myth2018 6y ago
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.
SQLite 6y ago
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 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.
- indigo945 6y ago
  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.
  - SQLite 6y ago
    See https://www.sqlite.org/fts3.html#custom_application_defined_tokenizers 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.

adamrezich 6y ago

Weren't all of these issues quickly fixed by the developers after being reported? E: oh whoops missed the dev post above mine

myth2018 6y ago

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.

SQLite 6y ago

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 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.

indigo945 6y ago
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.
- SQLite 6y ago
  See https://www.sqlite.org/fts3.html#custom_application_defined_tokenizers 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.