Zero page cache on close?


#1

As I understand it, the SQLite pager will cache pages read from disk. These will be cleartext.

On close, the cache is destroyed. Reading the code, that seems to simply involve truncation, which will leave cleartext page data in unallocated memory.

Is this the case? I would expect SQLCipher to zero-out the page cache when an encrypted database is closed.

If so, are there workarounds, or should I file an issue?


#2

Hello @rnewman - Thanks for getting in touch about SQLCipher.

Right now SQLCipher does not make an attempt to sanitize all memory allocated and used by the SQLite database code, instead focusing on sanitizing all allocations made by SQLCipher internally and of course securing data files themselves.

That said, one approach that we’ve recommended in the past for those particularly concerned with page cache is to simply disable it, e.g. pragma cache_size=0. Note however that there are other avenues for data to end up elsewhere outside of page cache, e.g. via memory-based temp tables, API allocations (e.g. used for returning values to the application), application front-end code, UI libraries, etc. Another option would be to use an application defined allocator, though then there can still be concerns about paging, etc.

Suffice it to say that complete sanitization is difficult in practice. However, we will look into improvements related to memory allocation/deallocation in upstream code as an improvement for a future release.


#3

Thanks for the reply.

I agree that general-purpose sanitization is very difficult.

However, I do think it’s worth considering the pager specially: not only is the pager responsible for the largest amount of allocated memory in SQLite, but while the application is in control of the creation of temporary tables and (to an extent) cursors and wrapper libraries, it has little control over this lower level.

Furthermore, setting cache_size=0 only works if you do it before running any queries, and presumably has a significant impact on query performance.

Would you like me to file an issue on the repo?


#4

I agree that it would be worthwhile to pursue this improvement. You’re welcome to open an issue in the GitHub repository for the core SQLCipher project, though if you’d prefer to save the time I think we have all of the information we need on the request documented here as well.


#5

Done, thanks!