Re: Ghost Data
Date: Sat, 4 Jul 2009 22:13:06 +0800
You may want to check the TDE FAQ, which I think answers your question.
Looking at the database file after encrypting existing data in a column, I can sometimes still see some of the clear text values. Why?
This is no different from finding the data still on the disk even after a table is dropped, or a file is deleted. During the lifetime of a table, data may become fragmented, re-arranged, sorted, copied and moved within the table space; this leaves 'ghost copies' of your data within the database file. When encrypting an existing column, only the most recent 'valid' copy is encrypted, leaving behind older clear-text versions in ghost copies. If the data file holding the table space is directly accessed bypassing the access controls of the database (for example with an hex - editor), old clear text values might be visible for some time, until those blocks are overwritten by the database. To minimize this risk, please follow these recommendations:
- Create a new table space in a new data file (CREATE TABLESPACE ... )
- Encrypt the clear text values in the original table space and data file (ALTER TABLE ... ENCRYPT)
- Repeat 2.) for all tables that contain encrypted columns
- Move all tables from the original table space into the new data file (ALTER TABLE ....MOVE... )
- Drop the original table space (DROP TABLESPACE). Do not use the 'and datafiles' parameter; Oracle recommends to use stronger methods for OS - level operations; see 6.)
- Use tools like 'shred', 'eraser', 'SDelete' or other commands for your platform to delete the old data file on the OS level.
The 6th step is recommended to lower the probability of being able to find ghost copies of the database file, generated by either the operating system, or storage firmware.
- Karl Arao http://karlarao.wordpress.com
On Thu, Jul 2, 2009 at 4:52 AM, Tanel Poder <tanel_at_poderc.com> wrote:
> When Oracle "new"-s a datablock in buffer cache it just updates the block
> header in the buffer and loads the inserted data in there, it does not fill
> the rest of the buffer with zeroes like OS'es do when faulting in new pages
> of memory into process address space. Thus if you get "lucky" you will see
> some ghost data in a hexdump of the block (but not in any query as the data
> logically does not exist anymore).
> From security perspective it may cause some issues if this issue is
> I'm not sure if the transparent tablespace encryption (which decrypts the
> data when reading a block in from disk) does anything to prevent a block
> with "ghost data" ending up used by some other segment.
> But in any case - if you can dump a cached buffer of a "ghost" block then
> you could dump the data from an encrypted tablespace's buffer as well, so
> there's no difference here. But if a buffer with some "ghost data" ends up
> being written into a non-encrypted "non-sensitive" tablespace, then this
> could be a problem.
> Tanel Poder
> On Wed, Jul 1, 2009 at 8:16 PM, Allen, Brandon <Brandon.Allen_at_oneneck.com>wrote:
>> Hi Martin,
>> No, I donít know which tables they were from since Iím not that familiar
>> with the application data. I could probably track it down if I needed too,
>> although it might be impossible to tell for sure since some of the data,
>> e.g. order numbers, probably exists in multiple tables. I donít see the
>> point in checking the rowid and source datafile though Ė I know that the
>> data is from somewhere else and is now showing up in my brand new datafile
>> that I just created.
>> Iím not very familiar with block dumps and not sure if Oracle will dump
>> blocks that it considers to be empty/unused since they arenít part of any
>> segment yet Ė do you know if it will and if so, how do I do it? Iím still
>> not sure what this would tell me either. There is no doubt that Oracle is
>> putting data into this datafile where it doesnít belong so I donít need to
>> verify that anymore Ė all I want to know is if this is normal behavior and
>> *why* it does this. Itís not really causing me any problems since I
>> donít have any encryption requirements and my server is secured so nobody
>> can go grepping through my datafiles anyway Ė Iím just curious.
>> Privileged/Confidential Information may be contained in this message or
>> attachments hereto. Please advise immediately if you or your employer do not
>> consent to Internet email for messages of this kind. Opinions, conclusions
>> and other information in this message that do not relate to the official
>> business of this company shall be understood as neither given nor endorsed
>> by it.
> Tanel Poder