sqlite: unauthorized information access [LWN.net]

Package(s):

sqlite

CVE #(s):

Created:

February 4, 2010

Updated:

February 15, 2010

Description:

From the Pardus alert:

A vulnerability has been found in sqlite, which can be exploited by malicious people to gather deleted information on sqlite database. Sqlite leaves a trace on the disk when using DELETE query. Although the deleted information cannot be seen with sqlite query, it can be seen with a text editor.

Alerts:

Pardus

2010-18

sqlite

2010-02-04

to post comments

sqlite: unauthorized information access

Posted Feb 12, 2010 17:58 UTC (Fri) by nlucas (subscriber, #33793) [Link] (3 responses)

This seems to me more like a bug (in the sense that it doesn't work as documented) than any real security problem.

If you have access to the file after the delete, then you also have access to the file before the delete, meaning you already can read whatever it is there.

The only security problem would be if using an encrypted sqlite database you could gain access to unencrypted data after a delete, which doesn't seem to be the problem.

sqlite: unauthorized information access

Posted Feb 12, 2010 18:37 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

Not quite - if I send you an SQLite file, you didn't have access to it before the deletion, but do now, you can read data I thought was deleted. Think of all the organisations that have been embarrassed by Word keeping change tracking revisions around in a document, for example.

I can't, off the top of my head, think of a real-world reason to distribute SQLite databases - but I can think of plenty of plausible reasons to do so (e.g. if you keep CDRs from an Asterisk box in SQLite), and it could get embarrassing if you disclosed information you thought had been deleted.

sqlite: unauthorized information access

Posted Feb 12, 2010 18:54 UTC (Fri) by nlucas (subscriber, #33793) [Link]

You do have a point in there.

On the other hand SQLite (don't think it's in the SQL standard) has the VACUUM command for that kind of situations. No need to use a specific SQLite compile option, which will incur in a small performance loss for everybody using the same library.

But I accept that VACUUM is not something you want to do every time (or set the "auto-vacumm" flag).

sqlite: unauthorized information access

Posted Feb 15, 2010 9:42 UTC (Mon) by mfedyk (guest, #55303) [Link]

> I can't, off the top of my head, think of a real-world reason to distribute SQLite databases

I can. Sqlite recommends using them for your file format. But I believe they recommend compacting before doing so which probably removes deleted records as well.