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

Veracrypt mounting same volume under 2 drives letters

Topics: Technical Issues
Sep 28, 2015 at 8:02 AM
I don't know why when I mount a volume let's say under letter M, it mounts it under M and uses another letter for example, S. I will have the same volume mounted under M and S but I don't need it to be mounted under the second letter. When I unmount the volume under M, it unmounts and the letter S remains as a ghost drive (Local drive) and there is no way to clear its assigned letter (it does not show under Disk Management). The only way is to reboot and S will be cleared. However, problems re-occur when M is mounted. I have around 6 volumes and most of them mount under 2 letters. Why? Am I doing anything wrong or this is a bug? (Windows 10, 64x). Volumes were previously Truecrypt and converted to Veracrypt. Pls help.
Coordinator
Sep 28, 2015 at 11:40 AM
Hi,

Can you please 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, like "\DosDevices\S:".
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 "TrueCrypt".

What is happening is that Windows remembers old drive letters associated with your volumes using TrueCrypt and he tries to use them automatically when you use VeraCrypt.
The main issue is that Windows uses an ID for the volume that depends on the file system and converting from TrueCrypt to VeraCrypt leaves this ID untouched. Moreover, we use in VeraCrypt an internal representation that is different from TrueCrypt and this makes Windows confused.

I'll see if it is possible to implement a workaround for this.
Sep 28, 2015 at 2:27 PM
Edited Sep 28, 2015 at 2:28 PM
I have had a very similar issue using the latest version (1.15), however my situation was a bit different:
  • Clean install of Windows 10 x64
  • 3 volumes: 2 old, encrypted with VeraCrypt, 1 created just today with latest VeraCrypt
  • Duplicated letters were appearing for the new volume and for one of the old volumes
I've tried deleting entries from "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices", but it didn't help - duplicated drives were created after reboot and remounting, just with different letters. What helped is switching to an older version of VeraCrypt, 1.0f-2, which was working fine for me before.
Sep 28, 2015 at 10:24 PM
Edited Sep 28, 2015 at 10:26 PM
@keleran,

Did you try removing the TrueCrypt entries and then reboot the PC before attempting to mount the volume?

Sometimes Windows "remembers" what is in the registry that is put in memory until reboot forcing Windows to read that part of the registry.
Sep 28, 2015 at 11:24 PM
This is the relevant issue. I've encountered the same problem on Windows 10.
Sep 29, 2015 at 5:54 AM
Hi Idrassi

Thanks for the tip. It worked like a charm.
Coordinator
Sep 29, 2015 at 8:03 AM
@keleran and @AlexanderGross: in your case, a good test would be to delete all entries under this registry key that reference VeraCrypt. Reboot and before mounting any volume, open all entries starting with "\DosDevices\", "\GLOBAL??", "#{" and "\??\Volume{" and delete those containing "VeraCrypt' in their data value. Then reboot and try again.
Sep 29, 2015 at 8:22 AM
@Enigma2Illusion,

Yes, I did.

@idrassi,

I've done it multiple times and it didn't help. Here are a few screenshots:

"This PC" after deleting all entries related to problematic drives and VeraCrypt and rebooting:

Image

"Disk Management", same state as above:

Image

"Registry Editor", same state as above:

Image

"Registry Editor", after mounting new VeraCrypt volume to P:\ and having duplicate drive D:\ appeared:

Image
Sep 29, 2015 at 11:07 PM
Edited Sep 29, 2015 at 11:08 PM
Does the "duplicate" need to be deleted from HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 in the registry?
Sep 30, 2015 at 3:57 PM
Same here. Today I switched from truecrypt. Everything is great, but after mount new volume (Z), always Vera Crypt mount also drive F.

Many times delete reg. and reboot. Still two drives.
Sep 30, 2015 at 9:04 PM
I also have the same issue using v1.15 on Windows 7 Pro. I just switched from TrueCrypt as well. When I mount the drive:

VeraCrypt.exe /q /d g:

I end up with the drive mounted on g: and an extra drive H: that I can't do anything with. This drive only goes away when I reboot my machine. It comes back after I mount another TrueCrypt volume using VeraCrypt.

Dan
Sep 30, 2015 at 11:00 PM
same here two drives for a mounted volume then one ghost drive for a dismountet volume. this is only at my notebook with Win7 pro, my desktop PC with XP and the other with Win7 is ok. All PCs upgraded from truecrypt to veracrypt
Sep 30, 2015 at 11:05 PM
Same double mounting problem - Windows 10, VeraCrypt version 1.15.

Whether I try mounting using the command line or the Windows application, a second drive letter is mounted along with the actual requested drive letter in the command.

Deleting the registry keys and rebooting had no effect.

I also just switched from using Truecrypt.
Oct 1, 2015 at 8:15 AM
Hi,

I have this problem in Win8.1 running VeraCrypt 1.15 (64-bit). This problem only surface if one use "Mount volumes as removable media" mount option. If you do not check this option, at least in my case, it will not do this.

VeraCrypt 1.15 (32-bit) running in the same OS does not create duplicate drives with this option.

I have just perform the test on VeraCrypt version 1.0f 2 32-bit and that version does not create duplicate drive, much like the behaviour of TrueCrypt.

Therefore it is fair to say VeraCrypt 64bit ver 1.15 running in Win8.1 causes duplicate drives to be produced when "Mount volumes as removable media" is selected.

Can someone please test my observation?

BTW, how can I remove the ghost drives now?

Thanks.

Leon
Oct 1, 2015 at 8:23 AM
keleran wrote:
I have had a very similar issue using the latest version (1.15), however my situation was a bit different:
  • Clean install of Windows 10 x64
  • 3 volumes: 2 old, encrypted with VeraCrypt, 1 created just today with latest VeraCrypt
  • Duplicated letters were appearing for the new volume and for one of the old volumes
I've tried deleting entries from "HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices", but it didn't help - duplicated drives were created after reboot and remounting, just with different letters. What helped is switching to an older version of VeraCrypt, 1.0f-2, which was working fine for me before.
Hi, Keleran,

I can verify that that old version (a 32-bit) does not cause that duplicate drive even when "Mount volumes as removable media" is selected. I tested that in a 64-bit Win8.1.

It appears the problem only surface in the Ver1.15 64-bit. Have you tried the Ver1.15 32-bit? My test shows that does not create duplicate drive (at least it does not use any ghost drives left behind created by previous VeraCrypt).

Leon
Oct 1, 2015 at 8:35 AM
Windows 10 PRO, 64bit.
I have this issue only on version 1.15
Version 1.14 is OK
Oct 1, 2015 at 9:14 AM
Hi LeonM2,

I haven't tried other versions and currently don't have much time to do tests, unless it would be requested by developers. You can remove ghost drives by deleting entries in the registry, in the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices branch.
Oct 1, 2015 at 10:15 AM
Edited Oct 1, 2015 at 10:16 AM
Hi,

I just installed VeraCrypt 1.15 on Win7 x64, coming from TrueCrypt, and mounted a former TrueCrypt volume. I got exactly the same problem. Cleaning up HKLM\SYSTEM\MountedDevices and rebooting fixed the issue.

What scares me is the simultaneous two volumes with the same content. They point to the same physical content. But are they considered as two distinct file systems by Windows? Or is one drive letter a link to the other one? The first case is dangerous. If, by accident, some files are accessed through G: (the ghost one here) and some others through K: (the real mounted one), there is a risk of unsynchronized access and consequently a file system corruption. In the second case, there is only one file system for Windows and then no risk of corruption.

Because of this, I hesitate to recommend VeraCrypt to my colleagues, long-time users of TrueCrypt, as long as this problem exists. I would recommend to fix the issue in the next version of VeraCrypt.
Oct 1, 2015 at 11:33 AM
I have the same problem here. The regedit trickery didn't help.
Oct 1, 2015 at 11:39 AM
lelegard wrote:
Hi,

I just installed VeraCrypt 1.15 on Win7 x64, coming from TrueCrypt, and mounted a former TrueCrypt volume. I got exactly the same problem. Cleaning up HKLM\SYSTEM\MountedDevices and rebooting fixed the issue.

What scares me is the simultaneous two volumes with the same content. They point to the same physical content. But are they considered as two distinct file systems by Windows? Or is one drive letter a link to the other one? The first case is dangerous. If, by accident, some files are accessed through G: (the ghost one here) and some others through K: (the real mounted one), there is a risk of unsynchronized access and consequently a file system corruption. In the second case, there is only one file system for Windows and then no risk of corruption.

Because of this, I hesitate to recommend VeraCrypt to my colleagues, long-time users of TrueCrypt, as long as this problem exists. I would recommend to fix the issue in the next version of VeraCrypt.
Hi,

On my test using Win8.1 I did not have to remove the ghost drives using RegEdit, just reboot the win8.1 will get rid of them.

All my tests use the same file container and all using "TrueCrypt mode" and all have "Mount volumes as removable medium" selected and the all the tests run in the Standard user's account and hence when I run up VeraCrypt I have to supply the Admin credential. That is fine.

In Win7 (64bit) VeraCrypt does not show creation of a duplicate drive in the Standard User's File Explorer even when I select to show all drives - empty or otherwise. But when I went to use the VeraCrypt "Select file and mount", the file open dialog box, now running with Administrator's account, shows the duplicate drive; if no file container is mounted it is a ghost drive and if a container is mount, it duplicates the contents. This is rather bizarre and clearly different from the Win8 behaviour I have observed.

I am quite happy to provide screen shots of this rather bizarre behaviour in Win7.

Please note that I also run the Linux version VeraCrypt 1.15 in Mint-17 and there is no duplicate "drive" problem - there is no drive letter in Linux.

Leon
Oct 2, 2015 at 12:14 AM
Same problem here. W7 x64 and VeraCrypt 1.15 and I just came from TC after reading about the severe vulns discovered. I truly appreciate the efforts in building this app but it is really frustrating having to deal with such bugs in a productions environment.
Oct 2, 2015 at 2:54 AM
Same problem here in Win 8.1 x64. Tried deleting the drives in the registry but they reappear after reboot.

Image
Oct 2, 2015 at 8:38 AM
lelegard wrote:
I just installed VeraCrypt 1.15 on Win7 x64, coming from TrueCrypt, and mounted a former TrueCrypt volume. I got exactly the same problem. Cleaning up HKLM\SYSTEM\MountedDevices and rebooting fixed the issue.
Bad news. After rebooting this morning, the problem reappears. But the scenario is strange:
  • Boot, no ghost drive
  • Mount legacy TC volume with VC on K:, only K: is present, no ghost.
  • "Dismount All" from VC, ghost drive F: appears, was not present before dismounting K:
  • Remount TC volume on K: again, drive F: is now mounted also with same content as K:
OK, this is too dangerous for a production system, I switch back to TC. The recent vulnerabilities (which were an incentive to switch to VC) seem less dangerous than the weird behaviour of VC. I will try again VC later, when it is more stable and reliable.
Oct 2, 2015 at 1:38 PM
This happening to me too.
Oct 2, 2015 at 4:50 PM
Edited Oct 2, 2015 at 5:23 PM
Having posted that it had worked, unfortunately I have now found that Idrassi's method has not worked; it just took a while for the ghosts to reappear
Coordinator
Oct 2, 2015 at 7:26 PM
Thanks to all for your comments and feedback.

The fix for the TrueCrypt vulnerability brings stability issues which are difficult to avoid at this stage. I'm working on a better fix but it proves very challenging. As I have written for the recycle bin issue (https://veracrypt.codeplex.com/discussions/645558#post1446829) there is a risk that it will not be possible to solve the TrueCrypt vulnerability without introducing instabilities like these ones.

Of course, it is out of question to leave this vulnerability open for exploits so the priority now is to come up with technical solutions that may even require a big change in the internal architecture.

I'll keep you informed.
Oct 3, 2015 at 8:00 PM
Edited Oct 3, 2015 at 10:15 PM
Idrassi -

Can you please explain why \DosDevices\I is pointing to Veracrypt VolumeH, when \GLOBAL??\H is pointing pointing to Verarypt VolumeH? This is in reference to the dual-drive issue that I am seeing after upgrading from Truecrypt to Veracrypt v1.15 (FYI - all registry entries were deleted that referenced Truecrypt before these screen shots were taken)

https://drive.google.com/file/d/0B7baCK78I2OrRi1NVXdRLVloNFE/view?usp=sharing

https://drive.google.com/file/d/0B7baCK78I2OrV1RwQTNpZWdLRkk/view?usp=sharing

Should this not be DosDecvices\H, instead, since it is actually pointing to Veracrypt VolumeH?
Oct 3, 2015 at 8:17 PM
lelegard wrote:
lelegard wrote:
I just installed VeraCrypt 1.15 on Win7 x64, coming from TrueCrypt, and mounted a former TrueCrypt volume. I got exactly the same problem. Cleaning up HKLM\SYSTEM\MountedDevices and rebooting fixed the issue.
Bad news. After rebooting this morning, the problem reappears. But the scenario is strange:
  • Boot, no ghost drive
  • Mount legacy TC volume with VC on K:, only K: is present, no ghost.
  • "Dismount All" from VC, ghost drive F: appears, was not present before dismounting K:
  • Remount TC volume on K: again, drive F: is now mounted also with same content as K:
OK, this is too dangerous for a production system, I switch back to TC. The recent vulnerabilities (which were an incentive to switch to VC) seem less dangerous than the weird behaviour of VC. I will try again VC later, when it is more stable and reliable.
At this moment, I agree. The POC provided by James Forshaw is local, only, and requires the password to the encrypted VOL to even prove the vulnerability exists.
Oct 4, 2015 at 4:08 AM
Fenderluvr wrote:
At this moment, I agree. The POC provided by James Forshaw is local, only, and requires the password to the encrypted VOL to even prove the vulnerability exists.
But the rogue local attacker could provide/create his own volume (with his own password) to exploit the vulnerability.
Oct 4, 2015 at 7:18 AM
Edited Oct 4, 2015 at 7:19 AM
kahuna0k wrote:
Fenderluvr wrote:
At this moment, I agree. The POC provided by James Forshaw is local, only, and requires the password to the encrypted VOL to even prove the vulnerability exists.
But the rogue local attacker could provide/create his own volume (with his own password) to exploit the vulnerability.
That may be true (not determined to be fact by POC, as far as I've read), but what is gained beyond proving the elevation of privilege abuse? That Truecrypt has bugs? All software has bugs, as we have seen from this mitigation fix in Veracrypt. It gains media attention because of the security audit, but the threat vector has really not been discussed in detail, IMO, and so I am not convinced that the threat is high enough to move to completely away from Truecrypt with so much buggy behavior from such a seemingly small code change.
Coordinator
Oct 4, 2015 at 8:40 AM
The Windows mount manager is the one responsible for associating \DosDevice\I with VolumeH: the big problem is that Windows mount manager seems to always try to associate the mounted volume with a local Dos device even though VeraCrypt explicitely associated this volume with the global Dos Device.

To protect against the attack, the chosen solution was to force all volumes to be mounted in the global namespace, which is what is intended in TrueCrypt and VeraCrypt. Doing so, causes the duplication since Windows mount manager create a new drive in the local namespace.

At this stage, it looks like the only solution would be to mount all volumes in local namespace but this will break the traditional usage where the drive associated with a mounted TC/VC volume is accessible by all users and services on the machine.

Unless a technical solution is found to block Windows mount manager from creating extra drive letters, there are two choices:
  • Leave the vulnerability unpatched in order to preserve the traditional TrueCrypt drive letters behavior.
  • implement a more stable fix for the vulnerability that will change the behavior of drive letter by making them local to each user on the system.
Comments and technical advises are welcomed.
Oct 4, 2015 at 10:11 AM
Thanks Mounir for this description and your work in general.

On a security standpoint, I would vote for a user-local drive. Mounting a drive accessible for one user only is better, in my opinion, in the sense that one user knows one passphrase for its own files and it seems logical to have him and only him accessing the encrypted volume. This is especially important in the context of a Windows terminal server environment. Moreover, in the case of a security breach through one service, the encrypted files remain unaccessible to the malware.

Of course, this breaks the traditional TC scenario. But, having my encrypted volume accessible to all users has always been the weak point of TC, as far as I am concerned. So, if VC can "fix" this, great.

One can say that this may break the operations when an encrypted volume was purposely mounted for multi-user usage. This is a problem, OK. So, there are two options: 1) If VC can, in some future version, support both options, system-wide or user-specific mount, the better. 2) In the near future, if an exclusive choice must be made, a user-specific mount will probably address more users' needs than system-wide.

Finally, and quite important, I assume that this dilemma only applies to containers and that encrypted partitions, system or non-system, are not concerned, meaning system-wide access and no duplicate drive letter, right ?
Oct 4, 2015 at 1:32 PM
Edited Oct 4, 2015 at 4:41 PM
idrassi wrote:
At this stage, it looks like the only solution would be to mount all volumes in local namespace but this will break the traditional usage where the drive associated with a mounted TC/VC volume is accessible by all users and services on the machine.
...
implement a more stable fix for the vulnerability that will change the behavior of drive letter by making them local to each user on the system.
IMHO it is not single user vs. multi-user issue.
Mounted volume must be accessible by all Windows services running under users like SYSTEM, Network Service, Trusted Installer token, and lots of things will be broken otherwise (impossible to run Search Indexer. impossible to make TEMP here, etc. etc.)

I suggest another workaround: restrict VC mount operations to the machine Administrators only.

BTW, how other Virtual Disk software (some of it is open source) handles this situation?
Oct 4, 2015 at 4:04 PM
Mounir,

First of all thank you for your work on veracrypt.

I have been following this thread with interest. When I have a little time I could take a look at the source code and see if I can suggest a "fix".

Meanwhile, I have noticed the following which may be a clue as to where the problem lies.

On my system the "Duplicated Mounted Volume" always appears mapped to G: (whatever letter I choose to mount to).

However, if I choose G: as the destination in the veracrypt GUI I don't get a "Duplicated Mounted Volume" and all is well. This is important
because it suggests that the windows mount manager is trying to duplicate the global mount points to local users but for some reason
it doesn't know which drive letter to use. Its either a bug in veracrypt 1.15 or a bug in the windows mount manager.

Wishing you all the best with your endeavors.
David
Oct 4, 2015 at 4:45 PM
idrassi wrote:
At this stage, it looks like the only solution would be to mount all volumes in local namespace but this will break the traditional usage where the drive associated with a mounted TC/VC volume is accessible by all users and services on the machine.
But wouldn't that mean nearly all encryption applications should be affected by this vulnerability? How does for example Bestcrypt handle the mounting? And since boot time mounting works, wouldn't it be possible to mount System Favorites too with the bootloader, that would at least fix a part of these problems.

I think until a real solution is found people should be able to decide themselves whats more important for them, either the original usability or security. Maybe you can add a setting for that in future versions.
Oct 4, 2015 at 6:24 PM
Edited Oct 4, 2015 at 6:30 PM
I have had only a very quick look at the code focused on the Mount Manager calls. A more detailed look will have to wait until I have more time.

In MountManagerMount(), two calls are made to TCDeviceIOControl(), first using IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION and second using IOCTL_MOUNTMGR_CREATE_POINT.

But I have noted that the "Duplicated Drive" shows up a bit later than the one that is requested in the GUI and I wounder if this could be due to Plug and Play service noticing the new devices arrival and then mounting it in the next drive letter for the current user.

I read This

which seems to suggest that IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION should not be used when Plug and Play device installer is running (it usually is). Instead the Mount Manage should be notified of the volume by means of the MOUNTDEV_MOUNTED_DEVICE_GUID device interface notification. (When plug and play is not running you can use IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION I think.)
Oct 4, 2015 at 6:30 PM
Edited Oct 4, 2015 at 6:40 PM
Ache wrote:
idrassi wrote:
At this stage, it looks like the only solution would be to mount all volumes in local namespace but this will break the traditional usage where the drive associated with a mounted TC/VC volume is accessible by all users and services on the machine.
...
implement a more stable fix for the vulnerability that will change the behavior of drive letter by making them local to each user on the system.
IMHO it is not single user vs. multi-user issue.
Mounted volume must be accessible by all Windows services running under users like SYSTEM, Network Service, Trusted Installer token, and lots of things will be broken otherwise (impossible to run Search Indexer. impossible to make TEMP here, etc. etc.)

I suggest another workaround: restrict VC mount operations to the machine Administrators only.

BTW, how other Virtual Disk software (some of it is open source) handles this situation?
I agree. You mean administrator context, yes?
Oct 4, 2015 at 7:06 PM
Edited Oct 4, 2015 at 7:07 PM
davidbe3 wrote:
I have had only a very quick look at the code focused on the Mount Manager calls. A more detailed look will have to wait until I have more time.

In MountManagerMount(), two calls are made to TCDeviceIOControl(), first using IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION and second using IOCTL_MOUNTMGR_CREATE_POINT.

But I have noted that the "Duplicated Drive" shows up a bit later than the one that is requested in the GUI and I wounder if this could be due to Plug and Play service noticing the new devices arrival and then mounting it in the next drive letter for the current user.

I read This

which seems to suggest that IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION should not be used when Plug and Play device installer is running (it usually is). Instead the Mount Manage should be notified of the volume by means of the MOUNTDEV_MOUNTED_DEVICE_GUID device interface notification. (When plug and play is not running you can use IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION I think.)
davidbe3, I think you may be on to something. It's been many years since I have reviewed NT driver code, but in reading your link point, it does seem (and through my testing) that the Plug and Play device interface notification mechanism may be doing exactly what you are saying. In my testing, the duplicate volume does not show up on initial mount, but instead some time later. I went back and read this This link to re-familiarize myself with what you are explaining, and what you say does make good sense. Well done!
Oct 4, 2015 at 7:26 PM
In my opinion, there has to be another way of mounting the encrypted volumes that does not expose the system to the two vulnerabilities identified and causing the severe limitations/issues to the users or OS processes. Otherwise, all other disk encryption software including closed-source commercial software would be impacted by these two vulnerabilities.

If the tech press is doing their jobs correctly, they should at least be asking encryption vendor's if their products are impacted by CVE-2015-7358 (critical) and CVE-2015-7359. This may have larger impact than just TC and VC users. Which would then lead to a larger community trying to solve the same problem.

Perhaps davidbe3's post will lead to the discovery for how to avoid the shortcomings of the current method in 1.15.

If no solution can be found, I request an option be added so the user can decide if they prefer the extra security of 1.15 method with the shortcomings listed (I noted 9 issues so far directly related to 1.15) or the legacy method listing in layman terms the security risks.
Oct 4, 2015 at 7:55 PM
Enigma2Illusion wrote:
In my opinion, there has to be another way of mounting the encrypted volumes that does not expose the system to the two vulnerabilities identified and causing the severe limitations/issues to the users or OS processes. Otherwise, all other disk encryption software including closed-source commercial software would be impacted by these two vulnerabilities.

If the tech press is doing their jobs correctly, they should at least be asking encryption vendor's if their products are impacted by CVE-2015-7358 (critical) and CVE-2015-7359. This may have larger impact than just TC and VC users. Which would then lead to a larger community trying to solve the same problem.

Perhaps davidbe3's post will lead to the discovery for how to avoid the shortcomings of the current method in 1.15.

If no solution can be found, I request an option be added so the user can decide if they prefer the extra security of 1.15 method with the shortcomings listed (I noted 9 issues so far directly related to 1.15) or the legacy method listing in layman terms the security risks.
Only my opinion, but I do not see this as an option if the project is to move forward and be supported and used by people on a large scale. The stigma of the very public vulnerability will keep people from using this very promising encryption software. IMO, a real solution must be found by heavy review of open source code that utilizes MountManagerMount(), and/or external code review assistance that davidbe3 has provided above.
Oct 4, 2015 at 8:26 PM
Fenderluvr wrote:
Only my opinion, but I do not see this as an option if the project is to move forward and be supported and used by people on a large scale. The stigma of the very public vulnerability will keep people from using this very promising encryption software. IMO, a real solution must be found by heavy review of open source code that utilizes MountManagerMount(), and/or external code review assistance that davidbe3 has provided above.
.
My request, if no solution can be found, is no different than the PIM feature which some people considered weakening VeraCrypt's security for the benefit of users that needed faster mount volume times even with the required 20+ character password length which is no guarantee that the user provided a longer and stronger password. It is the user's choice. :-)
Oct 4, 2015 at 8:39 PM
V 1.15 has only been released a short while ago.

We should give Mounir some time and I am sure he will be able to fix the vulnerabilities and solve this mount issue.

He might need to go for a long walk and forget about it for a few days, then come back to it.

I have built a difference report between veracrypt 1.15 source and Truecrypt 7.1a source. Not sure where to look for where the "Global" mounting namespace is specified. Both codes look similar to me.
Oct 4, 2015 at 8:46 PM
Edited Oct 4, 2015 at 8:50 PM
Oct 4, 2015 at 8:47 PM
Fenderluvr wrote:
Ache wrote:
I suggest another workaround: restrict VC mount operations to the machine Administrators only.

BTW, how other Virtual Disk software (some of it is open source) handles this situation?
I agree. You mean administrator context, yes?
Yes, it will be lesser evil.
Oct 4, 2015 at 8:49 PM
I just converted all my drives (VOLUME) from TC. Are those encrypted drives still impregnable? Can I continue to encrypt further drives?
Should I move to BestCrypt for which I have a paid license?
Oct 4, 2015 at 8:54 PM
jimmy1977 wrote:
I just converted all my drives (VOLUME) from TC. Are those encrypted drives still impregnable? Can I continue to encrypt further drives?
Should I move to BestCrypt for which I have a paid license?
Yes your encrypted volumes are still secure.
This thread isn't to do with the encryption at all, which is as solid as it was in TrueCrypt.
Oct 4, 2015 at 9:56 PM
Edited Oct 4, 2015 at 9:57 PM
jimmy1977 wrote:
I just converted all my drives (VOLUME) from TC. Are those encrypted drives still impregnable? Can I continue to encrypt further drives?
Should I move to BestCrypt for which I have a paid license?
You can go to this thread to read the explanation of the two vulnerabilities.

https://veracrypt.codeplex.com/discussions/645776
Oct 5, 2015 at 1:25 AM
Edited Oct 5, 2015 at 1:26 AM
davidbe3 wrote:
I have had only a very quick look at the code focused on the Mount Manager calls. A more detailed look will have to wait until I have more time.

In MountManagerMount(), two calls are made to TCDeviceIOControl(), first using IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION and second using IOCTL_MOUNTMGR_CREATE_POINT.

But I have noted that the "Duplicated Drive" shows up a bit later than the one that is requested in the GUI and I wounder if this could be due to Plug and Play service noticing the new devices arrival and then mounting it in the next drive letter for the current user.

I read This

which seems to suggest that IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION should not be used when Plug and Play device installer is running (it usually is). Instead the Mount Manage should be notified of the volume by means of the MOUNTDEV_MOUNTED_DEVICE_GUID device interface notification. (When plug and play is not running you can use IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION I think.)
The Plug and Play service is automatic and normally always running (there are several dependencies). MSDN goes even further to say, "This IOCTL allows clients to obtain drive letters for newly created volumes during text mode setup when the Plug and Play device installer is not running. Clients that have registered a device interface of type MOUNTDEV_MOUNTED_DEVICE_GUID in the normal way should not use this IOCTL. "

I'm sure a solution will be found, eventually, but I find the issue intriguing. :)
Coordinator
Oct 5, 2015 at 4:06 AM
Thank you for sharing your ideas and suggestions, especially davidbe3 and Fenderluvr.

The Mount Manager code should be rewritten and this will probably enable to solve the extra drive letter issue. But, the biggest problem with the correction of CVE-2015-7358 is that Windows behavior is completely different towards volumes created in the global namespace and this is something that was unexpected. This causes issues like the Recycle Bin one and I don't see a way to avoid this.

For now, I decided that the best approach is to implement a minimal fix for CVE-2015-7358 so that it will be very difficult for an attacker to abuse it: instead of creating volume in the global namespace, we only add checks at two strategic location in the code that will block any attempt to abuse a drive letter. This is enough in practice since it will extremely hard for an attacker to bypass those checks (this is also the opinion expressed in the CVE-2015-7358 description by James Forshaw).

You can get the installer of 1.16-BETA that implements this on: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

Unfortunately, the ideal solution (using global namespace) caused too much trouble. Putting everything in the local namespace doesn't solve the extra drive letter issue and it brings too much of a change for TC/VC users.

Concerning other encryption software, we can't be sure since there is no source code but I'm certain that at least some of them are impacted.

Can you please do tests on your side with the 1.16-BETA to confirm it solves issues?

Thanks.
Oct 5, 2015 at 5:20 AM
I have installed 1.16, and so far, the issue seems resolved. I will continue testing. On a side note, this issue:

(VC 1.15) Error 0x8007000F when deleting folders

seems to be resolved, as well. Please test to confirm.

Well done!
Oct 5, 2015 at 5:38 AM
Checking that NTSTATUS is equal to STATUS_OBJECT_NAME_NOT_FOUND before concluding that a drive letter is safe to use should prevent the first exploit on its own. You don't then need to use Global volumes. If a drive letter does not map to a volume, it cannot map to the C drive so the exploit is defeated. It doesn't matter that the C drive and veracrypt volumes are both local.

I think that the use of ? Operator in the code for the test is redundant. Just return NtSTatus == STATUS_OBJECT_NAME_NOT_FOUND.

In his work, JAmes Forshaw suggests a way to strengthen defence using local symbolic links which perhaps could be added in the future. Meanwhile the new beta is a good step forward. I will test when I have time.
Oct 5, 2015 at 7:04 AM
Edited Oct 5, 2015 at 7:05 AM
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.

I have done this, and so far 1.16 looks good.
Oct 5, 2015 at 3:13 PM
I cleaned up MountedDevices in the Windows registry as suggested by davidbe3, and then moved up to 1.16.

Looks good, drive ghosting issues seem to be eliminated, and deleting files/folders from mounted drive has not been a problem so far with 1.16
Oct 6, 2015 at 2:37 AM
Hi all,

Same observation as Sang41. All seems to be working. While logged in as a standard user (userA) I mounted one TC container into H: and a VeraCrypt file container into M: and all works nicely without duplicate drives. All Windows commands, such as Convert and create/delete folders seem to be work.

Then I did a switch user to another standard user and the H: and M: drives are there too.

I am wondering if this behaviour is correct: I did a switch user to another standard user (userB), bring up VeraCrypt 1.16 beta (I did not install it merely extracted it) and it allows me to dismount M: drive.

The auto-dismount - user log off, the default setting, even worked when I log off from userB.

So it seems everything works. Is this the fix we are chasing?

Thanks.

Leon
Oct 7, 2015 at 6:58 AM
Looks like the problem was solved here with 1.16-BETA!
Oct 7, 2015 at 9:51 AM
I have completed my testing. It has fixed it for me.
Coordinator
Oct 7, 2015 at 10:23 AM
Thank you for the confirmation. I will release version 1.16 in few hours.

@LeonM2: it is normal that mounted volumes are accessible by everybody on the system. by creating them in the default namespace, Windows exposes them globally on the system. One possible feature is to add the possibility to create volume in the local namespace for users but my initial testing showed me that the double drive issue also appear in this case. So, it will have to wait...
Oct 7, 2015 at 2:17 PM
Bestcrypt told me they should be safe, I don't really know much about these low level things but they said they have their own emulated bus created with an FDO where they mount their volumes then. Sounds like a lot of work to me...
Oct 8, 2015 at 8:23 AM
Edited Oct 8, 2015 at 8:31 AM
I haven't got any changes from update 1.16. When i mount a volume i get 2 disks. Moreover when I've started application from mounted disk, firewall has asked for approving this app from "second" disk.
btw, Windows Explorer doesn't see the "second" disk, I see it in total commander only.
Volume has been created in 1.15 version, does it matter?
Oct 8, 2015 at 8:46 AM
Edited Oct 8, 2015 at 8:49 AM
Follow the instructions below, but remove all entries containing veracrypt.

This will ensure all of the 1.15 volume history is removed from the registry. V1.16 should then work and you won't see duplicate drives.

The fact you created your volume in v1.15 doesn't matter.

Your firewall issue will also be fixed once you have only 1.16 entries in the registry.

idrassi wrote:
Hi,

Can you please 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, like "\DosDevices\S:".
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 "TrueCrypt".
May 12, 2016 at 8:56 PM
Edited May 12, 2016 at 9:14 PM
I have the same problem with the duplicate drives but it still occours in a freshly installed and formated Win10 with 1.17.
I have encrypted my two 3TB GPT drives without a partition (vc 1.17 wasn't able to use more then 2TB of a 3TB GPT partition), mounted them to Y and Z, set them as system favorites so they automount when booting from C with FDE and now I got disk 1 with drive letters A and Y and disk2 with B and Z.
Veracrypt only shows me the drives mounted as A and B and there is no Y and Z in veracrypts partition list.
Moreover I loose data because the NTFS rights management seems to go crazy with duplicate drives when changing folder rights. :(
Coordinator
May 12, 2016 at 9:54 PM
Did you try running the command "mountvol.exe /r" in an elevated command prompt after dismounting both volumes and rebooting?

Check also if the drives are not also present on the favorites list and that the option "Mount all device-hosted VeraCrypt volumes" is not checked in the Preferences dialog.
May 12, 2016 at 11:08 PM
Thank you very much idrassi. Now it works.

It was my fault. I checked the "Mount all device-hosted VeraCrypt volumes" in the Preferences dialog.