Not A Bug (1.21.2 ADDS a new user preference to control plugin networking) big privacy issue

[SPQR]

I think I found something that might be a critical security issue in latest vam1.
I'm 99% sure you can grab a user's vam data (screenshots, paid addons, IP) and send it silently to a 3rd party with a few lines of code in any var.
Where should I send it to? Probably not a good idea to post it here because it's very simple to exploit. If one of the mods can PM me and let me now that would be great!

 

[SPQR]

I made an example plugin with the exploit and sent it to MeshedVR directly. Wrote a bit more about it on my patreon https://www.patreon.com/posts/privacy-exploit-68979495

 

[lfe]

I made an example plugin with the exploit and sent it to MeshedVR directly. Wrote a bit more about it on my patreon https://www.patreon.com/posts/privacy-exploit-68979495

Does setting a firewall rule blocking outbound network connectivity work? I know I have mine setup like that.

 

[SPQR]

Does setting a firewall rule blocking outbound network connectivity work? I know I have mine setup like that.

I believe so, yes

 

[Ballard]

Wow keep posted on what you find out. Would love to hear a responce from Meshed on this.

 

[Sally Whitemane]

As far as I understand this is actually working as intended.
None of the VAM-security options restrict internet access for Plugins in general.
Many security options seems to be for the embedded browser.

Since whatever it sends back can only be from the VAM folder due to the 'System.IO'- and 'System.Reflection'-namespace restriction for Plugins I'm not concerned.
It's not like I store a wallet or bank-login data inside the VAM folder and for stealing paid content there enough easier ways.

If somebody is concerned about being tracked/IP leaks he/she cannot use Plugins. We all accepted the risk by enabling Plugins.
I really do not want another security restriction. I already wish the existing ones would be optional and only enabled by default.
Wish I could write a proper logfile for Plugin development. I cannot because 'System.IO' is blocked.

I don't see VAM as "attractive" target for bad guys unless they figure out ways to avoid existing security restrictions.

Creating a crypto-miner-Plugin for example would be stupid. Even if "Mr black hat wannabe hacker" tries to obfuscate the C# code, it still has to be compiled by VAM. It's impossible to hide. Somebody would look a the suspicious code pretty fast and discover that. It would be horribly inefficient with VAM eating CPU- & GPU-cycles too.

 

[VAMIC]

Any word on whether there's hope of a patch?

 

[SPQR]

Any word on whether there's hope of a patch?

it's kind of covered by that warning message you have to accept before using plugins, i wouldn't expect a patch unless something actually happens, hopefully it won't

As far as I understand this is actually working as intended.
None of the VAM-security options restrict internet access for Plugins in general.
Many security options seems to be for the embedded browser.

I wouldn't adventure to call it a feature lol. I mean, what's the purpose of blocking the web browser? It's reasonable to assume that the toggle there was added to protect users from things that could be done with the browser: pinging services automatically. I don't think it was added to let you force yourself not use the internet in vam as a self-imposed parental control. But then you have this that does the same thing but also much more on top of it since you can write files received remotely as well as send some files. It's not just that wannabe blackhat is gonna steal your plugin settings, but it could easily be used as a ddos tool or to get specific targets in trouble or extorted. I'm pretty sure you could go black mirror and give someone a heart-attack with surprise multiplayer.

Even if "Mr black hat wannabe hacker" tries to obfuscate the C# code, it still has to be compiled by VAM. It's impossible to hide. Somebody would look a the suspicious code pretty fast and discover that.

i somewhow doubt that lots of people are gonna jump to decypher obfuscated code for kicks. and certainly not in the places where things like these would more likely be used, barbarians central.

I don't see VAM as "attractive" target for bad guys unless they figure out ways to avoid existing security restrictions.

I don't know unity nor c# so I have no idea how secure vam is. Myself i don't like relying or hoping on people not being weird. People do weird stuff all the time, even just for lulz

 

[Almarcrux]

Since Vam can easily be blocked by things like windows firewall or TinyWall, I think that the worst result of a malicious plugin would be deleted files within the vam folder.

i somewhow doubt that lots of people are gonna jump to decypher obfuscated code for kicks. and certainly not in the places where things like these would more likely be used, barbarians central.

What does this mean? People are not gonna decipher the malicious code in places where this security exploit would be used? Like, where would you want to use this malicious exploit? What the hell are the "barbarians"?

 

[SPQR]

What the hell are the "barbarians"?

[redacted]

What does this mean?

i'm not gonna spell it out and give people naughty ideas for the sake of convincing people. If you think it's not serious or real, that's fine, idc.
Please don't turn this thread in a security experts convention. You guys can make your own thread and debate what you think is possible and impossible over there.

SOLUTION TO THE ISSUE BROUGHT UP IN THIS THREAD
- read carefully the red popup plugin warning before you hit accept
- block vam in a firewall if you don't want it to access data over the internet

 

[meshedvr]

This is really not a bug, but regardless I have added an additional user preference in the upcoming 1.21.2 release that can control if plugins are allowed to use networking or not. This user preference is off by default, so those wanting to use some of the plugins that require networking will have to opt-in to that feature.

 

[uqone]

This is really not a bug, but regardless I have added an additional user preference in the upcoming 1.21.2 release that can control if plugins are allowed to use networking or not. This user preference is off by default, so those wanting to use some of the plugins that require networking will have to opt-in to that feature.

This is the perfect fix for these things, not blind restrictions, but user choice. Thankyou!!!

Could we get a setting like this for the mentioned System.IO and System.Reflection restrictions as well? There are perfectly legitimate usages for both of these. eg: Windows TTS (which is badly needed in vam). Let us users choose! A scary popup telling people this could be a major risk on first plugin load, however, would be fine.

Would be awesome if it was a per-plugin setting. It would also be fine to block dll's and only allow readable C# code plugins to use these, so they can be easily community audited.

Honestly, VaM is quite possibly the greatest realistic virtual sandbox ever created, especially for VR. Blind restrictions should be avoided, warnings and opt-in's are enough.