SQL .mdf privacy violation - huge file contains personal contents

[Zytan]

I ran through the VB Guided Tour some time ago. In particular, the
"Managing Your Records: Using Data in Your Program" section:
http://msdn2.microsoft.com/en-us/lib...0s(VS.80).aspx

This explains how to create a SQL database, which is stored as an .mdf
file:
http://msdn2.microsoft.com/en-us/lib...99(VS.80).aspx
It is just 4 or 5 addresses being stored.

However, the database is 2,240 KB in size! To store 5 addresses? So,
I searched through the database, and I was SHOCKED to find about 120
KB of private IM conversations in there...

I predict the following occured: Firstly, the IM client released
memory without first clearing it. (A privacy violation, since other
programs can now read it.) SQL grabbed this memory, about 2 MB more
than would be reasonable, and didn't clear it. (A privacy violation,
since it will store this information until it is overwritten, and it
could contain personal information from your PC.) Then SQL filled a
small amount of this memory with the 5 addresses, and saved the entire
2.2 MB block. Funny how accidents always exposed several wrongs,
never just one.

I am shocked.

Question: How do I create a .mdf SQL file that DOESN'T contain un-
erased blocks of memory from my PERSONAL computer? (I am using VB
2005 Express)

Zytan

[David Browne]

"Zytan" <zy**********@yahoo.comwrote in message
news:11*********************@m58g2000cwm.googlegro ups.com...

>I ran through the VB Guided Tour some time ago. In particular, the
"Managing Your Records: Using Data in Your Program" section:
http://msdn2.microsoft.com/en-us/lib...0s(VS.80).aspx

This explains how to create a SQL database, which is stored as an .mdf
file:
http://msdn2.microsoft.com/en-us/lib...99(VS.80).aspx
It is just 4 or 5 addresses being stored.

However, the database is 2,240 KB in size! To store 5 addresses? So,
I searched through the database, and I was SHOCKED to find about 120
KB of private IM conversations in there...

I predict the following occured: Firstly, the IM client released
memory without first clearing it. (A privacy violation, since other
programs can now read it.) SQL grabbed this memory, about 2 MB more
than would be reasonable, and didn't clear it. (A privacy violation,
since it will store this information until it is overwritten, and it
could contain personal information from your PC.) Then SQL filled a
small amount of this memory with the 5 addresses, and saved the entire
2.2 MB block. Funny how accidents always exposed several wrongs,
never just one.

I am shocked.

Question: How do I create a .mdf SQL file that DOESN'T contain un-
erased blocks of memory from my PERSONAL computer? (I am using VB
2005 Express)

From

Database File Initialization
http://msdn2.microsoft.com/en-us/library/ms175935.aspx

Security Considerations
Because the deleted disk content is overwritten only as new data is written
to the files, the deleted content might be accessed by an unauthorized
principal. While the database file is attached to the instance of SQL
Server, this information disclosure threat is reduced by the discretionary
access control list (DACL) on the file. This DACL allows file access only to
the SQL Server service account and the local administrator. However, when
the file is detached, it may be accessed by a user or service that does not
have SE_MANAGE_VOLUME_NAME. A similar threat exists when the database is
backed up. The deleted content can become available to an unauthorized user
or service if the backup file is not protected with an appropriate DACL.

If the potential for disclosing deleted content is a concern, you should do
one or both of the following:

Always make sure that any detached data files and backup files have
restrictive DACLs.

Disable instant file initialization for the instance of SQL Server by
revoking SE_MANAGE_VOLUME_NAME from the SQL Server service account.
David

[Zytan]

David,

Thanks for the link.

If the potential for disclosing deleted content is a concern, you should do
one or both of the following:

Yeah, uh, I think they forgot the fact that it not only contains
deleted data, it also contains any information not zeroed out that any
program on your computer may have been using that was foolish enough
to not keep it private.

Just unbelievable...

I wonder how many people hex-search their database files? Not many,
so imagine who would know about this...

Disable instant file initialization for the instance of SQL Server by
revoking SE_MANAGE_VOLUME_NAME from the SQL Server service account.

I guess this is the solution. Wonder if it works for already created
SQL files? Doesn't sound like it will, but, perhaps.

Zytan

[Spam Catcher]

"Zytan" <zy**********@yahoo.comwrote in news:1170942148.428542.97430
@m58g2000cwm.googlegroups.com:

I predict the following occured: Firstly, the IM client released
memory without first clearing it. (A privacy violation, since other
programs can now read it.)

The .NET runtime handles memory management ... thus it should free +
clear the memory. However, I don't think you have a memory exploit issue
but rather a disk cleanup "problem".

SQL grabbed this memory, about 2 MB more
than would be reasonable, and didn't clear it. (A privacy violation,
since it will store this information until it is overwritten, and it
could contain personal information from your PC.) Then SQL filled a
small amount of this memory with the 5 addresses, and saved the entire
2.2 MB block. Funny how accidents always exposed several wrongs,
never just one.

SQL Server pre-allocates space for transaction logs, fill-space, etc. It
does this to speed up read/writes.

The IM conversions you're seeing may not be "buffer overrun" exploit but
rather old (deleted, orphaned, corrupted, etc) file system data. If this
is old file system data then it is pretty normal to be able to read the
old data back... but usually applications do clear it. However SQL
server may not bother due to performance reasons (on some large database
it could be grabbing hundred of MBs of free disk space at a time).

Or your disk may be corrupted - run a CHKDSK just to be safe.

I am shocked.

Don't be shocked - it's good to know that deleted data is not really
"deleted." You can recover year old deleted files depending on how often
your disk is being re-written!

Question: How do I create a .mdf SQL file that DOESN'T contain un-
erased blocks of memory from my PERSONAL computer? (I am using VB
2005 Express)

Run a disk shredding program. McAfee comes with one. I believe Spybot
S&D has one too (in the Advanced Tools section). Or:

http://www.heidi.ie/eraser/default.php

P.S. before you start blaming MS, here is an introduction to File Wiping
: )

http://en.wikipedia.org/wiki/File_wiping

[Zytan]

Spam Catcher,

I predict the following occured: Firstly, the IM client released
memory without first clearing it. (A privacy violation, since other
programs can now read it.)

The .NET runtime handles memory management ... thus it should free +
clear the memory.

I was running MSN 7.5. I don't know what version of the .NET runtime
it uses.

However, I don't think you have a memory exploit issue
but rather a disk cleanup "problem".

I don't believe so. The data I found was IM conversations that were
in memory, archived to disk, but never deleted. Unless the IM saves
them into temp files, which again, would be a privacy violation.
Either way, this private data, whether stored in memory temporarily,
or to disk temporarily, should be cleared, so it is not a privacy
violation. This is most certainly not an issue of my delete files,
which I know whose sectors will still retain the data until future
use, as I did not delete any such files.

SQL grabbed this memory, about 2 MB more
than would be reasonable, and didn't clear it. (A privacy violation,
since it will store this information until it is overwritten, and it
could contain personal information from your PC.) Then SQL filled a
small amount of this memory with the 5 addresses, and saved the entire
2.2 MB block. Funny how accidents always exposed several wrongs,
never just one.

SQL Server pre-allocates space for transaction logs, fill-space, etc. It
does this to speed up read/writes.

Ok. Understood. But 2,000,000 bytes for 500 bytes of data? I would
think perhaps a exponential scheme would suffice, rather than just
assume all DB will be of that size. But, I do understand that SQL is
meant for BIG programs, and the .NET access to them is just a service
to let us use it. It wasn't designed for small programs in mind. It
still surprises me, though.

The IM conversions you're seeing may not be "buffer overrun" exploit but
rather old (deleted, orphaned, corrupted, etc) file system data. If this
is old file system data then it is pretty normal to be able to read the
old data back... but usually applications do clear it. However SQL
server may not bother due to performance reasons (on some large database
it could be grabbing hundred of MBs of free disk space at a time).

Or your disk may be corrupted - run a CHKDSK just to be safe.

I didn't think this was a buffer overrun exploit. Because this isn't
a result of deleted files, I don't think the status of my disk system
is to blame. But, I certainly can check it just to be sure. A
previous posted showed that SQL doesn't zero out data for
performance. I just can't believe that this is the default setting.

I am shocked.

Don't be shocked - it's good to know that deleted data is not really
"deleted." You can recover year old deleted files depending on how often
your disk is being re-written!

I am not shocked that deleted data is still there... I'm familiar with
the old UNDELETE command, so I know all about this.

I am shocked at the privacy violations of SQL and Microsoft's IM.

Question: How do I create a .mdf SQL file that DOESN'T contain un-
erased blocks of memory from my PERSONAL computer? (I am using VB
2005 Express)

Run a disk shredding program. McAfee comes with one. I believe Spybot
S&D has one too (in the Advanced Tools section). Or:

http://www.heidi.ie/eraser/default.php

The other poster said to turn OFF (or is it ON) the setting inside SQL
that will make it zero data out. Although, I am not sure what use
this has for my private data already stored in the SQL databases I
have already made.

I am not concerned with people getting into my computer... if they do,
there's easier ways to get info from me than getting my SQL database
files. It's just that, what if i were to send a sample app to a
friend or something? My IM conversation is in there! It's absurb.
I'm sorry, but it is. Default settings should be security ON, speed
SLOW. Personal settings should be security OFF, speed FAST. I
imagine most people don't care, but then again, most people don't
know. When's the last time you searched your SQL databases with a hex
editor?

P.S. before you start blaming MS, here is an introduction to File Wiping
: )

http://en.wikipedia.org/wiki/File_wiping

I'm not anti-MS. I get my facts straight first. Somehow MS made my
IM conversation available to other apps. Yes, I do store history, but
I doubt SQL read in my history file. It happened by accidental use of
existing memory or disk that was not cleared. And yes, SQL is just as
much to blame for it. Even more so, since databases can be
transferred to other computers under normal conditions, IM histories
are not transferred without the owner explicit knowledge.

I know all about file wiping, btw. I've used apps like that before.

Zytan

[Spam Catcher]

"Zytan" <zy**********@yahoo.comwrote in news:1171035203.979585.100160
@k78g2000cwa.googlegroups.com:

I am shocked at the privacy violations of SQL and Microsoft's IM.

In fact it can be any file - whatever deleted file SQL server just happens
to reclaim.

Seems to be because your app is running under administrator mode:

http://msdn2.microsoft.com/en-us/library/ms175935.aspx

[Zytan]

I am shocked at the privacy violations of SQL and Microsoft's IM.

>
In fact it can be any file - whatever deleted file SQL server just happens
to reclaim.

I didn't delete any file.

But, yes, it can be any file or memory block that an application
containing sensitive data doesn't erase. In this case it was MSN 7.5.

Seems to be because your app is running under administrator mode:

http://msdn2.microsoft.com/en-us/library/ms175935.aspx

"Instant file initialization is available only on Microsoft Windows XP
Professional"

I am running WinXP Home, which implies zeroing should take place,
since I don't HAVE that feature.

Also, that article seems to imply the database is create ON DISK, and
then modified from there -- instead of being created in memory
(zero'ed out) and then written -- because it talks about what you are
saying - "Data and log files are initialized to overwrite any existing
data left on the disk from previously deleted files." That makes NO
sense. They create the data from used clusters on the disk, instead
of creating it in memory and writing it out, and letting the file
system take its place? Because if it did that, it would never HAVE to
read the data already stored on the disk (or leave it unchanged). I
can't believe this. But, now at least I understand where you are
coming from. But it does explain why it takes 30 seconds on a fast
dual core machine to load a database of 5 addresses. Maybe they use
memory mapped files or something like that. Also, it means MSN saves
this info to disk. Perhaps when it re-saves new conversation data, it
writes a new file, and deletes the old. Still a privacy issue.

I can't believe how security ignorant both of these programs have to
be to cause such an issue.

Thanks for your replies, Spam Catcher.

Zytan