When I change VMWare Workstation Pro 16 (16.1.2 build-17966106) Virtual Network Editor in Sandboxie, the change affect the real system

[0x391F]

Describe the bug
When I change VMWare Workstation Pro 16 (16.1.2 build-17966106) Virtual Network Editor in Sandboxie, the change affect out of the Sandboxie

To Reproduce
Steps to reproduce the behavior:
Original status:

1. Run VMWare Workstation Pro in Sandboxie with UAC Administrator privilege (otherwise couldn't startup any VM in Sandboxie)

2. Change the bridge adapter from Auto to physical network adapter (Realtek PCIe GbE Family Controller).
   

3. Click "OK" and exit

4. Clean up the Sandboxie

5. Run VMWare Workstation Pro, the bridge adapter changed to physical network adapter (Realtek PCIe GbE Family Controller)
   

Expected behavior
Any change inside Sandboxie shouldn't affect out of it.
Screenshots

System details and installed software (please provide the following information):

• What is your Windows edition and version? Windows 10 Enterprise LTSC 2019 (1809).
• What is your current Sandboxie edition and version? (Sandboxie Plus 0.9.3).

[DavidXanatos]

That is strange, changing other settings is contained but changing the bind adapter seams not very wired

[DavidXanatos]

So as far as I can tell the device "\Device\VMnetUserif" allows to configure VMNet0
its strange that its accessible its not configured open,
if its configured explicitly closed VMnet0 is no longer listed at all.

so as a workaround you can close that file path

[isaak654]

so as a workaround you can close that file path

ClosedFilePath=\Device\VMnetUserif

[0x391F]

Is there any way to redirect the change into Sandboxie rather than closed file path \Device\VMnetUserif ? Because we can't using bridge network (VMnet0) anymore in Sandboxie if the path is closed.

[isaak654]

How would you use a bridge network in Sandboxie? What's your use case?

[0x391F]

How would you use a bridge network in Sandboxie? What's your use case?

My computer have a big memory. I create and mount a RAM disk, the Sandboxie work folder is in it. I prepare some VM, and run VMWare in Sandboxie, link clone the VM, and it could properly work. If I want to reset the VM to initial status, I only need to clean the Sandbox. It only take a few seconds. Besides, page files and suspend to disk feature are disabled, so the secret in VM never written to the disk.

[isaak654]

I could consider to adjust the current fix, but I would need your help about the tests this may require.

EDIT: David just replied me that ClosedFilePath is the only possible solution here.

[isaak654]

@0x391F
If you really care I would recommend you to ask a second opinion to a security researcher for a fix that would balance your use case and in the same time preventing the isolation issue shown in the first post.

EDIT:
I would like to thank @diversenok for the additional evaluation provided on this issue.

[DavidXanatos]

It is a general flaw in sbies security architecture to allow Device IO Control access to random devices at \Device* this issue will be remedied in a later release.
for the issue at hand the result will be same as ClosedFilePath=\Device\VMnetUserif
hence if one wants to access that device OpenFilePath=\Device\VMnetUserif will have to be added
resulting in the initial issue at hand, device is open sandboxed apps can talk to it device driver modifies outside OS.

It is possible to add a driver level control code filter for this device, but as its not a part of windows and will be closed by default, its not something I would want to spend my time on,
i add a fix for one device driver and the world stays full of millions other device drviers that a good portion of will also allow to compromise the system still.

If this is something extremely important for someone, them one can become a patron at one of the 3 highest tears, then I would look into that custom solution for this particular use case.

[DavidXanatos]

The issue is taken care of by enabling the template DeviceSecurity
ofcause then no communication with VMnetUserif is possible but then one is secure.

The DeviceSecurity template uses the rule specificity feature to block all driver endpoints except the needed once, at least except those i knew are needed, probably some more would be needed to in more edge cases so it woudl be good to test this template and let me know if there is anythign else that should be open by defualt

[isaak654]

The issue is taken care of by enabling the template DeviceSecurity

It was removed on v1.0.16, any progress about the fix?

[DavidXanatos]

In one of the future builds a new hardened box mode will be introduced that prevents access to not opened device endpoints that will be the fix.
The user must choose if he wants to allow a particular sandbox access to this device or not. Its not reasonable to implement custom filtering for that endpoint.
If that means that then a sand boxed process can alter that tools configuration so be it.
Until then you can use ClosedFilePath=!vmware.exe,\Device\VMnetUserif or alike to allow only vmware.exe to access that endpoint but prevent all other processes from doing the same.

[isaak654]

Is there a technical reason not to apply the same endpoints restrictions to the standard box mode?

[DavidXanatos]

Yes there is, it may break compatibility with some other software, so we should keep it to me enabled manually if the user needs/wants it