405925 - ensure secure deletes for places.sqlite

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Description

[Dietrich Ayala (:dietrich)]

* ensure that secure delete is enabled
* quantify and document the details of how secure the deletes are

Comment 1

[(not reading, please use [e-mail] instead)]

in particular, we are talking about SQLITE_SECURE_DELETE

which we define here:

/db/sqlite3/src/Makefile.in, line 78 -- DEFINES = -DSQLITE_ENABLE_REDEF_IO -DSQLITE_SECURE_DELETE=1 -DTHREADSAFE=1

from http://lxr.mozilla.org/seamonkey/source/db/sqlite3/src/sqlite3.c?raw=1

#ifdef SQLITE_SECURE_DELETE
  /* Overwrite deleted information with zeros when the SECURE_DELETE 
  ** option is enabled at compile-time */
  memset(&data[start], 0, size);
#endif

and

#ifdef SQLITE_SECURE_DELETE
  /* If the SQLITE_SECURE_DELETE compile-time option is enabled, then
  ** always fully overwrite deleted information with zeros.
  */
  rc = sqlite3PagerWrite(pPage->pDbPage);
  if( rc ) return rc;
  memset(pPage->aData, 0, pPage->pBt->pageSize);
#endif

and

#ifndef SQLITE_SECURE_DELETE
        sqlite3PagerDontWrite(pPage->pDbPage);
#endif

note, we are just memsetting to zero.

perhaps we want an upstream sqlite feature request for "more secure" delete, that would write out random data (and write to disk x times) or what ever the right thing to do is?

note, other mozilla (and non-mozilla) sqlite consumers might want this, for example, nss.

Comment 2

[(not reading, please use [e-mail] instead)]

we might care about this for content-prefs.sqlite, cookies.sqlite, downloads.sqlite, formhistory.sqlite, search.sqlite, search.sqlite, etc.

note, SQLite 3.5.3 (the current version) still uses memset, so I've logged a feature request.  See http://www.sqlite.org/cvstrac/tktview?tn=2812

In addition to writing out random data (instead of memset() to 0), it appears that we're also supposed to do this and write to disk several times.  That part of "secure delete" may not be as easy (as just the random data part.)

Comment 3

[(not reading, please use [e-mail] instead)]

perhaps this bug should move to toolkit / storage?

Comment 4

[Jesse Ruderman]

I don't think it's worth the effort and perf hit to attempt to protect Firefox profile data from forensic data recovery.  It's really hard to get right, especially at the app level, and we don't want to give users a false sense of security by trying.

Any given data is likely to appear in many physical locations on the disk due to swapping, journaling, automated backups, and continuous defragmentation [1].  When you try to overwrite part of a file, you find yourself fighting against optimizations in operating systems and in disks themselves [2].  Data also appears in RAM, which can survive power cycling [2] and is even harder to control.

Zeroing sounds reasonable; it will protect against casual snooping, and depending on the file system, might protect against forensic software.  But I don't think we should go beyond zeroing (e.g. multiple overwrites) in an attempt to defeat forensic analysis of the physical hard drive and RAM.

Extremely paranoid users can use operating system features to encrypt an entire hard drive or automatically do multiple overwrites every time data on disk as it is changed.

[1] http://en.wikipedia.org/wiki/Disk_wipe
[2] http://en.wikipedia.org/wiki/Data_remanence

Comment 5

[Justin Dolske [:Dolske]]

I agree with Jesse. It's really ugly to try and solve this problem in the app. It's easier and more robust to handle this in OS, by using encrypted folders/filesystems.

Comment 6

[(not reading, please use [e-mail] instead)]

thanks jesse / justin.

Dr. Hipp agrees:

"I don't think writing random bits or writing multiple times
will help any.  There are too many layers (operating system,
file system, disk driver, and disk controller) in between
SQLite and the oxide for SQLite to really have much control
over what is truly stored on media.  SQLite might write the
same page multiple times, for example, but the OS would
likely coalese the writes into a single write.  Perhaps we
could force multiple writes using fsync() but that would be
a *huge* performance penalty.  And even if we did, just 
because we write to the same offset in some file does *not*
mean that the information is written to the same place on 
mass storage.  Some filesystems (YAFFS) intentionally spread
the writes around to different places for the purpose of
wear leveling.  And even if the operating system doesn't do
this, then on-drive disk controller might.

What problem, exactly, are you trying to solve?  The existing
SQLITE_SECURE_DELETE is adequate to prevent casual snooping.
It is not, as you observe, adequate to prevent snooping from
major governments.  Against a determined adversary, the only
sure defense is to physically shred the disk platter."

Comment 7

[(not reading, please use [e-mail] instead)]

Back to the original two issues:

> * ensure that secure delete is enabled

I've ensured it by code inspection.  

Were you thinking of compile time:

#ifndef SQLITE_SECURE_DELETE
#error "Zoinks, not building with secure delete" 
#endif

Or were you think about a test?  We might be able to develop a clever test to create / write / delete / quit and then attempt to casually snoop the file.  (I wonder if sqlite already has a test case for this?)

> * quantify and document the details of how secure the deletes are

I believe this bug now does this.

Comment 8

[(not reading, please use [e-mail] instead)]

Note, dcamp (for urlclassifier) and others may want to figure out a way to make secure deletes "per database" (with a pragma, maybe) instead of global per compiled instance of the code.

Comment 9

[Brandon Sterne (:bsterne)]

Since this is a dependency of bug 375898, marking P2 so it stays on our radar for Fx3 triage/tracking.

Comment 10

[Daniel Veditz [:dveditz]]

Agree with Seth in comment 7 that the intent of this bug appears to be satisfied

Comment 11

[Tracy Walker [:tracy]]

Verified per comment #10

Comment 12

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv