This project has moved. For the latest updates, please go here.

VeraCrypt 1.15 Recycle Bin not working on VeraCrypt drive

Topics: Technical Issues
Sep 28, 2015 at 10:15 PM
Just updated from 1.14 to 1.15 and now I'm finding that the Recycle Bin is not working on my container. I mount a file container as drive D: on my Windows 10 PC but if I delete a file from D: it always gives the confirmation prompt to permanently delete the file. Deleting from my system drive C: is OK.

If I right-click on the Recycle Bin and go to Properties, drive D: is not shown as a drive.
If I go into Admin Tools > Computer Management > Disk Management then drive D: isn't shown there either.
But D: does show in Windows Explorer and still seems to be working properly otherwise.
And Admin Tools > Disk Cleanup does show D: too.

Has something gone wrong with my upgrqade to 1.15?

Thanks.
Sep 29, 2015 at 3:24 PM
Same issue on Windows 7 Pro 64-bit OS using 1.15 version of VeraCrypt.

I created a test file on an encrypted volume, press the delete key and I am prompted to permanently delete the file instead of the prompt to move the file to the Recycle Bin.

I checked the Release Notes and there is no mention of changing the delete behavior.

I have created an issue ticket at the link below.

https://veracrypt.codeplex.com/workitem/227
Sep 29, 2015 at 8:17 PM
Edited Sep 29, 2015 at 8:25 PM
I can confirm that. Win 7 Pro x64.
System volume is fine, but other ones can't use the recycle bin anymore.

Btw: Checking the "Enable extended disk control codes support"-Box does'nt seem to be doing anything about this issue.
Sep 29, 2015 at 8:25 PM
My understanding is both Gnome77 and Arne001 are not using system encryption. Correct?
Sep 29, 2015 at 8:38 PM
No. I have been using it for years.
TC until a couple of days ago, VC since then.
Sep 29, 2015 at 8:42 PM
Edited Sep 29, 2015 at 8:51 PM
Thanks for the clarification Arne001. You are using system encryption and performing a delete will prompt you for the Recycle Bin, however performing a delete of a file on a non-system encrypted volumes prompts for permanent deletion. Correct?

Could you update the ticket in my post above with this information? It may help Mounir troubleshoot the issue.
Sep 29, 2015 at 8:54 PM
Enigma2Illusion: that is correct for me. My system drive C: is NOT encrypted and the recycle bin works fine there. Drive D: is an encrypted, non-system file container mounted manually as part of my startup routine.

I'm pretty certain that version 1.14 didn't have this issue.

My Win10 is 64bit Home if that matters.
Sep 29, 2015 at 9:01 PM
Edited Sep 29, 2015 at 9:55 PM
Correct.
Everything is encrypted. But since 1.15 the recycle bin does not show any volumes other than the system one, so naturally there is no choice other than permanent delete of any file on these non-system volumes. I have'nt checked if the hidden folder which win uses for the recycle bin is lost. Free space seems to indicate it though.

The loss of everything in the recycle bin would be a potentially very harmful result of upgrading to 1.15 and consecutive mount of a non-system volume.

Edit: The files which have already been in the recycle bin don't seem to be lost. The folder is still there. If I try to open it, it only shows the deleted files on the system partition, but the hidden recycle bin-folder itself on the non-system volume is still big and has a lot of files in it (which I can't see as long as Windows does'nt let me activate the recycle bin for this particular volume).
I hope this was understandable.

This raises another issue: As long as the recycle bin cannot be activated, it can't be emptied or deactivated, therefore everything that is in it cannot be properly deleted.

My guess is that losing the ability to activate the recycle bin on non-system volumes has something to do with fixing the elevation of privilege vulnerabilities.
Apparently since VC 1.15, I'm allowed to see the recycle bin-folder but not those contents of it which are located on non-system volumes.
Sep 30, 2015 at 8:41 AM
Same here on two machines.

The Recycle Bin disappears from non-system volumes, when they get mounted with the option "Mount system favorite volumes when Windows starts (in the initial phase of the startup procedure)" checked.

The Recycle Bin re-appears when above option is unchecked. But then I have other problems with Windows when I choose this, since my Documents, etc have been moved to the non-system disk.

System volume is fully encrypted, non-system disks have the same pass-phrase+PIM.
Sep 30, 2015 at 12:58 PM
The Volume is just mounted in a very weird way.. It's not displayed in the disk management utility for example and many applications give weird error messages (I can't open some doc-files in Word for example and i can't create folders from the file browser).

Does the system favorite mounting even work for you guys? It still doesn't on my system, Windows 10 x64.
Sep 30, 2015 at 3:55 PM
gamerto wrote:
The Volume is just mounted in a very weird way.. It's not displayed in the disk management utility for example and many applications give weird error messages (I can't open some doc-files in Word for example and i can't create folders from the file browser).

Does the system favorite mounting even work for you guys? It still doesn't on my system, Windows 10 x64.
I can confirm that system favorite mounting does work on Windows 10 x64. File Explorer works fine, backups work fine (except for VSS, but that's another known problem). Only problem is the Recycle Bin.

I am using encrypted disk partitions and a combination of Truecrypt (older disks) and Veracrypt (newer disks) encryption. I haven't tested with Veracrypt file containers.
Oct 1, 2015 at 8:39 PM
It's actually a little more than the Recycle Bin - it's almost like the volumes are being mounted as removable. I use "Search Everything" and it no longer (since 1.15) recognizes the volumes as fixed drives so it won't include them in its index. In older versions that worked fine.
Oct 2, 2015 at 8:53 AM
Edited Oct 2, 2015 at 8:53 AM
It's true! All encrypted system favorite disks, even the system disk, appear as removable on the "Safely remove hardware and eject media" icon.
Coordinator
Oct 2, 2015 at 12:58 PM
Hi all,

This is a confirmed side effect of the critical elevation of privilege issue. It makes volumes belong to the global namespace anf this forbids many of the usual actions.
A better fix is in preparation but it proves difficult...actually there is a need for a big architecture change in the handling of volume drive letters otherwise it will be impossible to fix the vulnerability without these side effects.
The current approach inherited from TrueCrypt is simplistic and it proves to be deadly...releasing the fix was important because I'm sure this vulnerability is known to attackers and it may have been already used. The last words of TrueCrypt developers seem to have more meanings now...

I'll let you how things go and if this is fixable without side effects or not. This is the most difficult time for TrueCrypt and its forks like VeraCrypt and I will do my best to put everything back on track.
Oct 3, 2015 at 11:24 AM
anf this forbids many of the usual actions.
What else? Is Veracrypt still safe to use, especially in terms of data loss?
Oct 3, 2015 at 4:09 PM
Edited Oct 3, 2015 at 4:13 PM
To bump Arne001's question: is it safe to stay with v1.13 to prevent data lost of a corrupted Recycle bin?
I have not updated from 1.13 yet, I'm afraid to if there is a possibility data will be corrupted.

Keep up the good work idrassi, As always, your efforts are more appreciated then we can put into words!
Oct 3, 2015 at 5:43 PM
I did read the VC 1.15 release notes about the elevation bug in TC/VC, however I could not figure out how the bug can be exploited by an attacker to compromise the security of VC/TC. Can someone explain in a more or less easy to understand language, what is this bug all about (as from Idrassi's comment it sounds quite an issue)?
thanks
Oct 4, 2015 at 2:45 AM
Edited Oct 4, 2015 at 2:45 AM
Alex512 wrote:
I did read the VC 1.15 release notes about the elevation bug in TC/VC, however I could not figure out how the bug can be exploited by an attacker to compromise the security of VC/TC. Can someone explain in a more or less easy to understand language, what is this bug all about (as from Idrassi's comment it sounds quite an issue)?
thanks
.
See thread below.

https://veracrypt.codeplex.com/discussions/645776
Oct 4, 2015 at 7:29 AM
Edited Oct 4, 2015 at 7:33 AM
Just wondering something: I always keep my drives set to (remove files immediately). In that case, is this not an issue then?

Also, does the new fix in v1.15 (which validates the drive letter symbolic link) reintroduce the past issue we had with running Tor? See thread below.
https://veracrypt.codeplex.com/discussions/642465

And last:
Do the updates to v1.15 require encrypted drive headers to be updated?
Coordinator
Oct 4, 2015 at 8:00 AM
For those who don't require the vulnerability fix, I advice you to install version 1.14 that was released 10 days before 1.15.
Version 1.14 solves some issues described in its release notes. It is the most stable version before 1.15 which was an emergency release.

You can get version 1.14 on Sourceforge: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%201.14/ (The release note of 1.14 are on the bottom of the page).

Concerning your fears of data loss and Tor stability, there is no risk: the Tor issue was solved and it has nothing to do with drive letters. The recycle bin issue and the drive letter duplication are related to Windows interfacing for volumes and it doesn't impact data storage.

As I explained above and also here, the vulnerability maybe unfixable unless we make mounted volumes only accessible to the user who mounted them.
Oct 4, 2015 at 9:23 AM
Thanks for the details and specifics idrassi!
You're doing a great job. Thank you for being so passionate and dedicated to this project!
Oct 4, 2015 at 11:58 AM
Edited Oct 4, 2015 at 12:18 PM
idrassi wrote:
For those who don't require the vulnerability fix, I advice you to install version 1.14 that was released 10 days before 1.15.
There is a problem: downgrading VC is not possible without system partition decrypting and encrypting back now with older version (from installer's error message). Could you please release, say, v1.15a with elevation fix backed out, so installer will treat it as upgrade without reencrypting needed?
Coordinator
Oct 5, 2015 at 3:21 AM
I have released a beta version of 1.16 that solves this issue. Details in my post here: https://veracrypt.codeplex.com/discussions/645527#post1447038
The installer is here: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

Basically, CVE-2015-7358 fix was modified to avoid the encountered Windows side effects while maintaining protection against practical attacks. Theoretically, the modified fix can still be abused but it will be extremely difficult and in real world situation it will be almost impossible.

I will wait for extra tests by the community before releasing the 1.16 but at this stage everything looks fine.
Oct 5, 2015 at 10:40 AM
Good GRIEF!!! I just got bit by this bug. Ouch, ouch, ouch.

Would you recommend I go back to v1.14, or go to v1.16 beta to avoid this huge problem?
Oct 5, 2015 at 5:01 PM
Edited Oct 5, 2015 at 8:49 PM
SHBouwhuis wrote:
Good GRIEF!!! I just got bit by this bug. Ouch, ouch, ouch.

Would you recommend I go back to v1.14, or go to v1.16 beta to avoid this huge problem?
.
Upgrade to Beta 1.16 version will resolve the issues.

davidbe3 wrote:
People who have tried 1.15 will have to remove any entries containing "Veracrypt" from the MountedDevices registry hive first or 1.16 won't always work properly.
.
Using a modified version of Idrassi's instructions:
Check the registry key "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices" using regedit. Scroll down and you'll find entries starting with "\DosDevices\" which indicate the drive letters that are taken by the system. Before mounting any volume, remove the ones that are unused.
Also, there are other entries whose name start with "#{" and "\??\Volume{": double click on each one of them and remove the ones whose data value contains the name "VeraCrypt".
Oct 5, 2015 at 5:42 PM
@Enigma2Illusion
Ok, I did both things and the recycle bin works again.

Many thanks!
Oct 5, 2015 at 9:39 PM
Too complicated, too risky, not really official.
I rather wait for a final installer which fixes all this automatically.

I can spare the bin for a couple of days...although if I had known the 1.15 issues, I'd have waited with upgrading. It's not gonna happen to me again. You live and learn.
Nowadays being very cautious and updating rightaway often seems to do more harm than it has benefits.
Oct 5, 2015 at 9:41 PM
I installed 1.16-BETA and forgot to do all the registry stuff first but it worked great as is. I'd recommend going with it - idrassi is obviously a good judge of weighing the risks of the compromise vs. features, and this worked out well in the end !!
Oct 5, 2015 at 9:47 PM
Edited Oct 5, 2015 at 9:53 PM
I feel safer knowing that something is not working and knowing what it is than I would if everything seemed to work fine but you could not be sure.

I trust idrassis word ("there is no risk"), I don't trust myself to manually bustle around Veracrypt registry entries.
Oct 6, 2015 at 12:44 AM
Edited Oct 6, 2015 at 12:49 AM
One quick question for idrassi, or anyone here who might have the facts on the question:

When upgrading from say v1.13 to the 1.16-beta, or even the final release, do the headers on our volumes need to be updated to take advantage of the security issues addressed in this new releases? Or do these fixes only effect to the driver in windows specifically?
In other wolds, should I change my passwords on all my volumes/containers which essentially re creates / updates the headers on the volumes, or just update the base program?



Advanced Thanks
Oct 6, 2015 at 2:04 AM
Hello movingkey,

You can read explanation at the following thread.

https://veracrypt.codeplex.com/discussions/645776

You do not need to update the header keys. The two recent vulnerabilities are due to the TrueCrypt/VeraCrypt drivers. Merely upgrade the software to 1.16 version and reboot your PC.

Kind Regards.
Oct 6, 2015 at 5:16 AM
Thank you Enigma2Illusion!