[18889] in bugtraq
EFS Flaw - Tidbit
daemon@ATHENA.MIT.EDU (Attonbitus Deus)
Tue Jan 30 18:41:04 2001
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <001901c08ad6$d501e700$af05a8c0@anchorsign.com>
Date: Tue, 30 Jan 2001 08:07:45 -0800
Reply-To: Thor@HAMMEROFGOD.COM
From: Attonbitus Deus <Thor@HAMMEROFGOD.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
After vehemently defending the procedures outlined in the many articles,
KB's, and publications from MS regarding the best practices of EFS use, I
have come across some new information (to me, anyway) which mandates that I
consume a morsel of crow.
After continuing to experiment with different procedures, I found that the
EFS0.TMP file is NOT created in the path set in your TEMP/TMP environment
variable, but rather in the source drive of the newly encrypted file.
AFAIAC, this changes things a bit. So, even if you did follow the procs to
the letter and encrypt your Temp dir so that all newly created temp files
were also encrypted, you would still leave this guy in plain text by
default. Granted, they always say to create new files in encrypted dirs,
but given this caveat, I have to agree that the issue carries more weight
than I originally maintained. Since they don't follow the TMP environmental
variable, the temp file should indeed be wiped, or it should not allow you
to encrypt individual files in the first place.
So, though I still maintain that the exploitability of this issue is remote,
I must acquiesce to Rickard and Dan's statements as being factual. If the
true location of the temp file was known all along, then I apologize for
dragging this thing out as I did.
Thanks to all.
---------------------------------
Attonbitus Deus
Thor@HammerofGod.Com
