Bugtraq mailing list archives
Re: BugTraq: EFS Win 2000 flaw
From: Dan Kaminsky <dankamin () CISCO COM>
Date: Wed, 24 Jan 2001 21:52:27 -0800
Recommended EFS procedures call for the encryption of a direcory, not file-by-file as the procedure indicated by Berglind suggests. If you copy
an
unencrypted file and paste it into an encrypted directory, the file and
the
temporary file are both encrypted. This is actually covered in the docs regarding EFS.
Ahem. Been seeing alot of this. RTFM is actually not the correct response to a security hole--among other things, "the docs" is insufficient information for me to determine which is the canonical and mandatory docs I'm supposed to address as The One And True Docs. If you ask me, the user interface itself is the most important documentation--it's the only thing that, if it's incorrect, is *guaranteed* to lead to the wrong thing being done. The user interface states that a file can be taken from an insecure state to a secure state by checking "encrypt file". That's it. You get a warning, and the warning states that unless the folder as a whole is encrypted, a change in the file might lead to decrypted content being saved. That's it. I think my real problem with people running to the docs is that, quite frankly, the *reason* for something to be recommended is *critical*. According to the UI itself, the reason folder-crypto is superior is because "modified files might be saved in cleartext." According to the "Step By Step Guide To EFS" (http://www.microsoft.com/technet/win2000/efsguide.asp), the reason it's recommended is "because many existing applications are not aware of encryption and can therefore render the file in clear text." Assume I've read both pieces of documentation--if I don't plan to modify the file and if I'm using non-legacy applications, I should be safe. After all, if the real recommended reason was "use of this feature will render the encryption completely irrelevant to anyone with a sector editor", why, the feature wouldn't even be in Windows, wouldn't it? MS is failing to overwrite, even once, either the original file or the .tmp file that EFS creates. That's a bug. It's not *nearly* as significant as the possibility that MS was plaintext writing *everything*, and just converting to encrypted form in the background(which is exactly what I thought it was doing), but it's an issue and they're likely to address it. Simply recommending a given pattern of behavior is irrelevant. Nobody should be faulted, not even slightly, for passing over the recommendations given that they were given without reasons that Rickard made clear. Yours Truly, Dan Kaminsky Cisco Systems, Inc. http://www.doxpara.com
Current thread:
- BugTraq: EFS Win 2000 flaw Rickard Berglind (Jan 19)
- Re: BugTraq: EFS Win 2000 flaw Alexander Ivanchev (Jan 22)
- Re: BugTraq: EFS Win 2000 flaw Dan Kaminsky (Jan 24)
- <Possible follow-ups>
- Re: BugTraq: EFS Win 2000 flaw Russ (Jan 22)
- Re: BugTraq: EFS Win 2000 flaw Dan Kaminsky (Jan 23)
- Re: BugTraq: EFS Win 2000 flaw Timothy J. Miller (Jan 23)
- Re: BugTraq: EFS Win 2000 flaw Ryan Russell (Jan 23)
- Re: BugTraq: EFS Win 2000 flaw Jeremy Epstein (Jan 23)
- Re: BugTraq: EFS Win 2000 flaw Attonbitus Deus (Jan 23)
- 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 Dan Kaminsky (Jan 23)
- Re: BugTraq: EFS Win 2000 flaw Alexander Ivanchev (Jan 22)
- Re: BugTraq: EFS Win 2000 flaw Ryan Russell (Jan 24)