3 ms·

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

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

by SQLite 6y ago

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.