Bugtraq mailing list archives
Reply to EFS note on Bugtraq
From: Ryan Russell <ryan () SECURITYFOCUS COM>
Date: Mon, 22 Jan 2001 17:28:50 -0800
Due to some mail trouble, I'm manually forwarding this note. The signature should check out. Ryan From: Microsoft Security Response Center Sent: Monday, January 22, 2001 2:17 PM To: 'bugtraq () securityfocus com' Cc: Microsoft Security Response Center Subject: Re: BugTraq: EFS Win 2000 flaw -----BEGIN PGP SIGNED MESSAGE----- Hi All - While EFS does indeed work as Rickard discusses, this is not new information. For instance, "Encrypting File System for Windows 2000" (http://www.microsoft.com/WINDOWS2000/library/howitworks/security/encr ypt.asp, p 22) notes the following: "EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. NOTE: Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file." The plaintext backup file is *only* created if an existing plaintext document is coverted to encrypted form. If a file is created within an encrypted folder, it will be encrypted right from the start, and no plaintext backup file will be created. Microsoft recommends this as the preferred procedure for using EFS to protect sensitive information. "Encrypting File System for Windows 2000", page 22, makes this recommendation: "... it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc." Even if the plaintext backup file were not created, it would still be a bad idea to create a sensitive file in plaintext and then encrypt it later. Many common operations, such as adding data to or removing data from a file, compressing and decompressing a file, defragmenting a drive, or opening a file using an application that creates temporary files, can result in plaintext being left on the drive. It is simply not feasible for any software package to be able to track down and erase all the plaintext "shreds" that may have been created during the file's plaintext existence. The only way to ensure that there is no plaintext on the drive is to encrypt the file right from the start. Nevertheless, we are investigating this issue to see whether there are improvements we can make. No matter what the solution, it will still be better for customers to create sensitive files encrypted from the start; however, we believe it may be possible to prevent the plaintext backup file from being retained on the drive. Regards, Scott Culp Security Program Manager Microsoft Security Response Center - - -----Original Message----- From: Rickard Berglind <Rickard.Berglind () EIKNES SE > Sent: Fri, 19 Jan 2001 12:29:50 +0100 To: BUGTRAQ () SECURITYFOCUS COM Subject: BugTraq: EFS Win 2000 flaw I have found a major problem with the encrypted filesystem ( EFS ) in Windows 2000 which shows that encrypted files are still very available for a thief or attacker. The problem comes from how EFS works when the encryption is done. When a user marks a file for encryption a backup-file, called efs0.tmp, will be created. When the copy is in place the orginal file will be deleted and then recreated, now encrypted, from the efs0.tmp- file. And finally, when the new encrypted file is succesfully created, the temporary-file ( which will never be shown in the user interface ) will be deleted as well. So far, so good. The only file remaining is the one which is encrypted. But the flaw is this: the temporary-file is deleted in the same way any other file is "deleted" - i.e. the entry in the $mft is marked as empty and the clusters where the file was stored will be marked in the $Bitmap as available, but the psysical file and the information it contains will NOT be deleted. The information in the file which the user have encrypted will be left in the backup file efs0.tmp in total plaintext on the surface of the disk. When new files are added to the partition will they gradually overwrite the secret information, but if the encrypted file was large - the information could be left for months. So how can this be exploited ? If someone steals a laptop or have psysical access to the disk it will be easy to use any low level disk editor to search for the information. For example, the Microsoft Support Tool "dskprobe.exe" works fine for locating old efs0.tmp-files and read information, in plain-text, that the user thought was safe. In my opinion there should be a function in the EFS which physically overwrites the efs0.tmp at least once to make it a lot harder for an attacker to gain control over secret information. Here is a description how to test this : Use any version of Windows 2000. Install the Support Tools from the Win2000 CD. For demonstrating purposes - create a new partition with the size of 7 MB. Choose to format with NTFS. Create a new small file ( easier to find ) with Notepad and put some text in it. Save this file in the root of the new partition. Do not encrypt it yet. Let us look at the file through DiskProbe before encryption- start Diskprobe from Support Tools on the Start Menu. A. Choose the "Drives"-menu and "Physical Drive" Double click on "physical drive 0" ( or other drive you are using ) Click "Set active" and then "OK" B. Choose "Drives" again and this time "Logical Volume" Double click the drive letter for your new partition and then "Set active" and "OK" C. Choose the "Sectors"-menu and "Read". For starting number type 80 and for the number - 35 perpaps. Maximize the window and click the arrow for "Next sector". At sector 86 you should see the name and contents of your file ( assuming you made a new partition ) The file is obiously in plain text and easy to read for anyone with physical access to this disk, regardless of permissions in the ACL, which is ignored when using this kind of utiliy. Better encrypt this file .. ! Now close the DiskProbe utility and open Explorer and locate your new file. Choose Properties - Advanced - Encrypted - OK. The file is now encrypted. Wait a few moments to be sure the new data has been written to the disk. Open Diskprobe again and repeat steps A, B and C. When reaching sector 86 you should be able to see the name of your file, but not be able to read the information - it is now encrypted. But.. continue to click the Next Sector-Arrow and look carefully at the information being displayed. A few sectors away from the orginal file there should be a file called efs0.tmp - which is the backup file EFS creats during encryption. You should ALSO be able to see the contents of this efs0.tmp file - which will be the data from the file you encrypted. The problem is just that the data is in clear and plain text. So again - anyone with physical access to this disk can read the data you thought was safe. / Rickard Berglind -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOmyxM40ZSRQxA/UrAQHFQgf/U0sEgP/amXjGQaeNJoYDd1L+58V0TWy/ 9j5nlQzWgbAy480vL0RuIglZwGZJJmXYe0xMgoy9DjZ4zFbMxeFx8l30K6kzfnDI LuLyyvnhwA1rfVpYZoThAPX5pU1tQ9IowyzVW0E8IUXFYBa8Y55MB1J4QUPcMqq6 U+1a7y2gkXGcN7+WwtauSvPx8m350Z8k5+BgI8DWI5iM6ddqnHX/M22EFVzbLWpb ZITeaZdZoyDZtB6UdmbPg0FJf8RVntSDe3d0EK3hKjdt/MyOXnJC6PvE5RzAQJ4+ 566TZjn4HPq+loQkn+Ihr9VnNOuGrOxLZXY6hGRDPMpVrczvnCQHSw== =tQGb -----END PGP SIGNATURE-----
Current thread:
- Reply to EFS note on Bugtraq Ryan Russell (Jan 23)
- win32/memory locking (Re: Reply to EFS note on Bugtraq) Peter W (Jan 23)
- Re: win32/memory locking (Re: Reply to EFS note on Bugtraq) James Perry (Jan 24)
- Re: win32/memory locking (Re: Reply to EFS note on Bugtraq) Keith Ray (Jan 24)
- Re: win32/memory locking (Re: Reply to EFS note on Bugtraq) James Perry (Jan 24)
- win32/memory locking (Re: Reply to EFS note on Bugtraq) Peter W (Jan 23)