Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: BugTraq: EFS Win 2000 flaw
From: Ryan Russell <ryan () SECURITYFOCUS COM>
Date: Wed, 24 Jan 2001 11:33:28 -0800

I've got a couple of question on this issue..

The concern is that a temp file of the original plaintext may be left
around for an attack to "undelete".  It's understandable why this might be
neccessary for a rollback in case of machine failure at just the wrong
time.  (Though one could argue that that's what backups are for.. since
you could lose the file to a blackout either before or after the encrypt
operation, I'm not so sure why it's such a big deal if you lose it
during.)

Where does the encrypted file go when it's done?  Does the OS make sure it
goes back on the same sectors where the original unencrypted file was?  If
not, then then original plaintext file is lying around with the delete
flag set, and the temp file is a bit of a moot point.

If the crypted bits are carefully written over the plaintext bits, then
yes, the temp file being left in plaintext on disk seems like a silly
mistake.

How about this set of steps to ensure careful overwriting of plaintext:

-Leave plaintext file where it is for the moment
-Create a temp file which consists of the crypted version of the plaintext
-Swap file names (file.txt and file.txt.tmp) The file with the .tmp
extension is now the plaintext version.
-Copy crypted bits over the plaintext bits (i.e. copy file.txt
file.txt.tmp)
-Mark file.txt.tmp as deleted

There are points during this process where you can halt the machine, and
there will be a plaintext version left on disk.  Since you started with a
plaintext on disk to begin with, it's not possible to create a set of
steps that might be interrupted at the wrong time and not leave plaintext
on the disk.  At least, not if you want to maintain the rollback feature.

None of this takes into account the possibility that one can get previous
generations of writes via some mechanism.  Heck, it doesn't even take into
account that the drive might decide all of a sudden that it doesn't like
that sector anymore, and remap it under your OS' nose, without it knowing
a thing about it... leaving the original sector physically on the disk, at
the top layer of writes, but totally unavailable to normal software.

Which boils down to me agreeing with Dan's statement... the only way to
make sure your plaintext doesn't come back to haunt you is to never write
it to disk.  For EFS, I believe this would require you taking a virgin
drive and creating nothing but EFS partitions that cover the entire drive,
and THEN do your work.

                                        Ryan


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault