1.26.29 VeraCrypt Mounts Without Password (macOS)
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hi,
yesterday I updated VC to latest and by request also fuse-t:
VeraCrypt_FUSE-T_1.26.29
fuse-t-macos-installer-1.2.7
OS is MAcos Tahoe latest
restarted.
previously i had mounted a veracrypt file based volume and opened a text file on it with TextEdit.
veracrypt is not running.
Textedit remembers recently opened files and i see the name of my file from my encrypted volume.
when i select it, WITHOUT asking for a password , the encrpted volume mounts and the file opens.
WHAT?
I have set in seurity preferences
unmount all volumes when veracrypt quits
wipe cached passwords on exit and on auto-unmount
Something I do wrong or is this a bug?
i must admit that I am not a Mac user, so ignore this if it makes no sense.
Is it possible that textedit is caching the file?
In MS Word, for example, a backup/copy is saved, so that should a crach or reboot happen before the file is saved to disk, when Word re-opens it will take you back to where you were, by loading the backup/copy from a different location.
If textedit has this functionality, maybe the "copy/backup" is not saved on the veracrypt volume, and so can be re-loaded even without the original source (the veracrypt volume) being mounted.
I cannot see any way, that a file could be read from an unmounted volume - an unmounted volume is just a large blob of random data. however, it is very possible that there could be leakage, such as mentioned above - a copy/backup/cache saved to a temp folder or other non-encypted location.
I found this on the internet:
What you're seeing is very likely TextEdit/macOS Auto Save and Resume, not access to the VeraCrypt volume itself.
When you open a file in TextEdit, macOS will create an autosaved copy in the user's Library area, such as:
~/Library/Containers/com.apple.TextEdit/
~/Library/Autosave Information/
The autosaved content is stored on your normal system volume, not necessarily on the original disk where the document resides.
So the sequence can be:
Open secret.txt from a VeraCrypt volume.
Edit or view it in TextEdit.
Reboot.
VeraCrypt volume is not mounted.
Launch TextEdit.
TextEdit restores the document from its autosaved/restored state.
The content you're seeing may be a cached copy, even though the original file is inaccessible.
caching could be a problem, but in this case not only TextEdit opens the file, but also the volume gets mounted
Thank you for reporting this.
VeraCrypt doesn't store volume passwords in macOS Keychain or any persistent password store. Cached passwords are kept only in VeraCrypt process memory. So, if a VeraCrypt volume is fully unmounted, it shouldn't be possible to mount it again without entering the password.
The most likely explanation is that the volume was still mounted, or that the unmount didn't fully complete because TextEdit/macOS still had a file handle open. In that case, selecting the recent file in TextEdit would simply reopen a file from an already mounted filesystem, so no VeraCrypt password prompt would appear.
Please check the following immediately after quitting VeraCrypt, before opening the file from TextEdit recent items:
If any VeraCrypt/FUSE-T/hdiutil mount is still present, then the volume was not fully unmounted.
Also, please try after a full reboot: don't start VeraCrypt, then open TextEdit and select the recent file. If the volume really mounts from a clean boot without VeraCrypt running and without asking for the password, that would be unexpected.
One more note: macOS/TextEdit may keep the filename/path in its recent-items list. That doesn't by itself mean the encrypted data is accessible: the important point is whether the volume is still mounted and the data can be read.
Thanks Mounir for VeraCrypt and the response and hints what to check.
After some testing i found:
Answering your questions:
mount | grep -Ei 'veracrypt|fuse|smb|veracrypt_aux'
-> nothing
hdiutil info | grep -Ei -B4 -A8 'veracrypt|volume.dmg'
-->nothing
ps axo pid,comm,args | grep -Ei 'VeraCrypt|veracrypt|fuse|fuse-t|mount_smbfs|diskimages'
ls -ld "$TMPDIR"/.veracrypt_aux_mnt* 2>/dev/null
-->nothing
My current workaround at the moment is killing the nfs process.
I do not know since when this issue shows up and if its related to go-nfsvv4 or smb or Veracrypt not telling the nfs to quit.
Any help appreciaated....IMHO this is a serious risk.
regards
Hello,
To be honest, I'm surprised at the lack of response to my post.
In my opinion, this malfunction poses a huge risk to anyone using Veracrypt-fuse on a Macintosh.
Can someone please run the test on a comparable system?
Mounir IDRASSI, what do you think? Are you working on an update and does it affect Veracrypt or fuse-t/nfs?
Is there another channel where I should report this bug?
I look forward to answers
Feedback geben
Hi,
Your report is not ignored. In fact, another user has reported the same issue on Github which I replied to yesterday: https://github.com/veracrypt/VeraCrypt/issues/1779
I have been working on this. Short answer: there is an issue in FUSE-T backend related to unmounting which leaves FUSE-T process running. I'm trying to find the best approach to handle FUSE-T unmount, especially when done through Finder which is outside the control of VeraCrypt.
There are other issues reported in relation to FUSE-T. It is clearly less stable than the historical macFUSE that is robust. FUSE-T is popular because it doesn't require kernel extension.
One aspect concerning my apparent lack of feedback: everyday, I receive queries through direct emails related to questions and issues for VeraCrypt, in addition to the various topics and issues opened on Sourceforge and Github everyday. They touch Windows, Linux and macOS and they are related to various issues and requests.
I do my best to analyze and respond to everyone, but there is a problem: VeraCrypt doesn't generate revenue for me. So, I have to look for projects and customers to earn my living. I do receive donations and they are helpful, but their level is not enough to cover the work on VeraCrypt. As everybody knows, the business environment is becoming tough, and technology evolves quickly specially with AI, so I need to spend time adapting and prospecting.
Anyway, concerning your issue, my short-term advice: uninstall FUSE-T and install/configure macFUSE (https://macfuse.github.io/). It is not as simple to configure as FUSE-T but it is robust and it has a stable track record (of course, after installing macFUSE, you need to install macFUSE version of VeraCrypt using the link on VeraCrypt website).
Once I have a solution for FUSE-T issues, I will post an update.
Thank you very much! I wasnT aware of the github issuse and do as advised.