How? It can’t run code on the host system. It is true you will now have a malicious file present on the host’s filesystem, but if you don’t run that file, and nothing else runs the file for you, it won’t infect the host. (Granted, there is the risk of malware dropping, say, a malicious JPEG that your host’s file manager’s thumbnailer is exploited by. That is a concern, so I guess if that’s what you mean by “weakens the isolation”, that’s a valid criticism.)
1 Like
How? It can’t run code on the host system. It is true you will now have a malicious file present on the host’s filesystem, but if you don’t run that file, and nothing else runs the file for you, it won’t infect the host. (Granted, there is the risk of malware dropping, say, a malicious JPEG that your host’s file manager’s thumbnailer is exploited by. That is a concern, so I guess if that’s what you mean by “weakens the isolation”, that’s a valid criticism.)
As far as I know, Stuxnet was initially spread through an infected usb. It infected an airgapped Iranian nuclear power plant, then somehow escaped containment and managed to infect external Iranian computers, leading to antivirus companies discovering it. If that is possible without any user interaction (without running the file for example), then I would imagine that a sophisticated virus that infects the shared partition could spread to the host system without any user interaction.
Granted, not everyone’s threat model includes active NSA hacking attempts or viruses like Stuxnet. And I do not know the details about viruses like Stuxnet.
IIRC (and assuming Wikipedia was correct), Stuxnet used a zero-day in Windows Explorer’s thumbnailer, which is the type of exploit mentioned above. So while technically using a shared folder shouldn’t meaningfully affect the guest’s access to the host system, the host system’s applications could still do things that result in compromise, and this is not a theoretical concern. I misunderstood what “weakens the isolation” meant initially.
There are other possible mechanisms that could be used for clipboard sharing beyond a shared folder; you could run a network service in the VM that listened on a port that was forwarded to the host and could not be accessed from the outside world. That would potentially open up the host system to having its network stack exploited by the VM though (assuming that’s not already the case; VirtualBox’s NAT implementation probably exposes the host’s network stack to some degree as attack surface).
Until Oracle fixes the bug (or someone gets the time to fix it), various non-ideal solutions like this are probably all that can be worked with. I would argue that a shared folder is probably safer than communicating over a network port, provided that one ensured no host software other than whatever you’re using to copy things to the clipboard accessed it. That would reduce the risk of things like thumbnailer compromise.
1 Like
I don’t understand how the script I shared is a security risk?
The script you shared is not (AFAICT) a security risk on its own. The discussion above was talking about the security risks of using shared folders in general.
2 Likes
I am not a programmer and cannot evaluate the security of the script .
As I already understood from communication on the forum , it is safe .
Above I wrote that I always have several instances of Whonix (1 instance = Gateway + Workstation)
Therefore , your option does not suit me, even if you can run several such scripts at once, it will simply drive me crazy .
Anyway thanks for the proposed solution .
Old CVE of VB shared folders: NVD - CVE-2017-3587 It’s impossible to guarantee the absence of such unknown vulnerabilities. But that’s not the primary threat.
The main point is that Whonix 18 requires storing a file with highly sensitive data. This file on host OS contains passwords, logins and everything else that passes through the clipboard in case of Whonix 17. This is an extremely inconvenient and insecure approach even with encrypted container.
1 Like
Correction: All Wayland based operating systems currently require this.
I completely agree with both statements .
I feel extremely sad because I had to stay on Whonix 17 which is almost out of support and I can’t switch to Whonix 18 because of the broken Shared Clipboard .
Yes. But we are comparing Whonix 17 and Whonix 18 (None-Qubes, Virtual Box both). You require users to upgrade to v.18 but do not warn about new and extremely serious risks of v.18.
These risks of Whonix 18 involve having to shared folder and permanently recording all sensitive data in a text file that is not encrypted by default. An always-open shared folder with Whonix 18 creates an additional attack opportunity because such Virtual box folders had a confirmed old vulnerability and may have unknown vulnerabilities (just like any other part of VB).
The main risk affects all confidential information that moved through the clipboard without being saved to disk in previous Whonix versions where clipboard sharing was not broken. All such content (passwords, logins, texts) Whonix 18 user must write to an unencrypted file on the host OS. People should clearly understand the consequences since Whonix 17 did not have a similar problem and this threat is new.
It seems advisable to write a separate wiki-text about this aspect of Whonix 18. Such text could include:
- explanation of Wayland broken clipboard sharing issue with a clear warning that it has been unresolved for a long time and may never be resolved
- warning about neсessity to save an unencrypted file with confidential data on the host OS
- advice to Whonix 18 users to store this insecure file inside an encrypted container at least
I can prepare a draft of such text for the wiki if you agree.
I don’t know if I’m pointing out the obvious or not, I apologize if so, but it seems that there’s a misconception in this thread that using a shared folder in lieu of clipboard sharing comes with a strictly higher attack surface than clipboard sharing used to. It really doesn’t. Clipboard sharing comes with its own set of potentially serious risks:
- A compromised VM can read anything that goes through the host’s clipboard, including, say, credit card numbers and other data that is tied to your identity, as well as encrypted data such as passwords.
- It could also load malicious data into the host’s clipboard, causing the compromise of other apps when that data is pasted.
- Clipboard sharing has different attack surface in VirtualBox, it’s possible the code VirtualBox uses to talk to Guest Additions could be vulnerable to attacks.
- VMs that shouldn’t be allowed to talk to each other can now communicate arbitrary data to each other over the clipboard, potentially allowing an anonymity leak if a compromised Whonix-Workstation VM can talk to a compromised other VM on the same host.
- If the attacker just wanted to mess with you, they could break the clipboard entirely by constantly copying an empty string to it.
There are probably more dangers, but this is enough to make my point. All of the above attacks are mitigated when using a shared folder instead. That doesn’t mean that the shared folder is strictly an improvement over the security of clipboard sharing, but it does mean that the threats are different and users will have to adjust accordingly.
So far the two worst problems with folder sharing that have been pointed out in this thread are the possibility for a VM to compromise the host’s file manager or related programs via crafted data (like compromising Windows Explorer’s thumbnailer), and the fact that sensitive data will be stored unencrypted on disk. The first can be mitigated to a great extent by disabling any form of file previewing on the host (Kicksecure does this out of the box already, so if you’re using a Kicksecure host you get this “for free”). The second can be mitigated by placing the shared folder on a tmpfs (in-RAM filesystem) under Linux. If you’re using Windows, ramdisks aren’t a thing, so maybe VeraCrypt volumes with throwaway keys will work. If both mitigations are in place, shared folders might be more secure than clipboard sharing.
2 Likes
You can add your description of these known clipboard sharing risks to wiki-warning which I propose. But your message don’t affect Whonix 18 users as clipboard sharing is broken in v.18. It’s more important to warn about the real risks. Most Whonix 18 users write sensitive information to file as Whonix team abviced to do it. And not everyone realizes that file is extremaly insecured, unencrypted and can be compromised or recovered long afterward.
Fair enough, I just wanted to point out that this isn’t a step backwards security-wise and the risks here are no more extreme than the risks with the previous method.
Feel free to propose a wiki edit. The encrypted container idea you listed is a good idea, that would definitely be a welcome addition.
1 Like
See also Improve the Documentation / Edit the Whonix Wiki.
WIki page:
Once that wiki page has more information, the virtualizer specific chapters,
can have a notice box / link to that wiki page to read about the advantages and disadvantages of either method.
Related (for source code, but similar for wiki editing):
We need a write-up that factually documents the whole topic. Otherwise meanwhile we can just write 1 sentence and link to this forum discussion.