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
Current thread:
- Re: BugTraq: EFS Win 2000 flaw, (continued)
- Re: BugTraq: EFS Win 2000 flaw Dan Kaminsky (Jan 24)
- Re: BugTraq: EFS Win 2000 flaw Attonbitus Deus (Jan 25)
- Re: BugTraq: EFS Win 2000 flaw Kirk Corey (Jan 25)
- Re: BugTraq: EFS Win 2000 flaw Attonbitus Deus (Jan 25)
- Re: BugTraq: EFS Win 2000 flaw Ryan Russell (Jan 24)