Status of Drag'n'Drop

[J.L.]

I'm interested to know if there is any progress for non-Linux guests. Like roadmap, ETA, or anything like that. Thanks.

[mpack]

Moved to "Suggestions".

Yep, the roadmap is known, the road terminates at a big red sign saying "No Entry".

Are you aware of the malware implications of supporting drag and drop from host to guest?

If not, then consider how just that one feature would be implemented. Then consider how that feature might be abused.

<hint>Don't confuse the user paradigm with reality. Moving a mouse cursor doesn't do anything, it ultimately just causes an instruction to be sent. Which implies that a certain piece of code inside the guest must be capable of carrying out such instructions. What capabilites would that piece of guest code need to have?

[J.L.]

Malware implications... you mean from guest to host? Cause the other way around you're screwed anyways.

Why not remove the feature entirely, or are somehow Linux guests immune to malware?

Would the new hardened mode help?

[mpack]

If you consider the implications as I asked then you should have been able to answer some of those questions yourself.

And, I would not have allowed the feature for Linux guests either. I think the devs put their toe in the water and then realized they didn't want to go any further. They didn't delete the feature, they just made it default to disabled. I suppose the argument for Linux guests was that it's harder to hide malware in open source code.

Hardened mode has nothing to do with this. We're talking about apps running in the VM (not in the VB host process), talking to API functions native to the VB code.

Drag and drop from host to guest: the most obvious implementation implies that the guest has the ability to open and read files anywhere on the host, whether or not a virtual network exists. So, what people think of as a sandbox could conceivably harbor malware which scans your host's hard drive and extracts email addresses, bank details, purchase histories, etc etc and transmit them via the internet to interested third parties.

Drag and drop from guest to host: implies that the guest has the above ability, plus the ability to write and modify files anywhere on the host, whether or not you have created a virtual network connection. I shouldn't need to elaborate on what malware could do with this.

It's like sharing your entire host hard drive on the Internet: yum yum, come and get it boys!

[J.L.]

About guest to host, can malware modify files without Windows prompting you? I assume unless you run as admin, it will be limited in where it can write as well. Still can be bad though, so I've disabled it. Didnt think about the implications before.

[mpack]

About guest to host, can malware modify files without Windows prompting you? I assume unless you run as admin, it will be limited in where it can write as well.

VBox is running in your user account space, so it will be limited to parts of your drive which you can access. More precisely it means anywhere that could possibly be either source or dest for a drag and drop operation. That probably means no access to System folders, or other user folders.... which on my PC would mean it can still access everything on my PC that matters. I.e. stuff in the System folder can affect system stability, but none of it is confidential. It does mean it probably can't rootkit you.

I'll correct one thing: I said earlier that guest code running in the VM is not running as a host process. I'll take that back. On reflection, all code running on the host CPU must be included in an executable code section running as part of the VBox host process. However the important point remains the same: guest malware would be using advertised features of the VBox API, it wouldn't need to use any fancy tricks such as DLL injection and hence wouldn't be blocked by the hardening rules.