Earlier this week at the DEF CON security conference, Omar Gull from from Check Point presented an attack against SQLite. The creative technique demonstrated by the security researcher uses a specially modified database to compromise an application querying the database file, facilitating Remote Code Execution.
Since SQLCipher is based on SQLite, users are naturally concerned with whether this also affects SQLCipher. The following comments address these concerns:
- The underlying issue exploited in the attack using FTS3 was patched by the SQLite team in 3.28.0. As a result, the same fix is present in SQLCipher 4.2.0, since it is based on 3.28.0. We strongly recommend that all applications upgrade to SQLCipher 4.2.0 to take advantage of the latest security updates, especially if an applicaiton interacts with non-encrypted databases using SQLCipher.
- The standard mode of operation for encrypted SQLCipher databases provides some built-in protection against this attack vector, even if an earlier version of SQLCipher is used. This class of vulnerability takes advantage of the fact that standard SQLite databases can be manipulated prior to use by a target application. By directly modifying the sqlite_master table, the target application is “tricked” into executing the attacker’s statements. Using SQLCipher encryption directly mitigates that risk because SQLCipher databases can’t be manipulated without the database key. Valid database content can’t be created without the key and any attempts to modify the database otherwise would invalidate the per-page signatures (MACs) stored as part of the database. In other words, SQLCipher provides a way for applications to ensure that encrypted databases has not been manipulated externally to inject malicious code.
As a result, most applications using SQLCipher encrypted databases should be secure against this sort of vulnerability even when an attacker has access to the database file, provided that the attacker does not also know the corresponding database key material.