Big security risk with global sharing

Its not often that customers get to interact with the people who write their software, so I for one am greateful at any opportunity to hear directly from a development team, or for the team to hear directly from me.

This is a quite curious thread, though I am only compelled to respond to add another name to the tally for passers-by.

We all must remember that perspective is the filter of our universe. "Secure" and "easy" are subjective adjectives and likley have different meanings to us and the majority of Parallels users.

As serv said, most Parallels users that I know just need to get things done. In the Mac world, things are typically "easy" and just plain work. Every question you have to ask a user is a step away from easy. If a novice user needs to edit an MS Access database, they know that they need to edit an MS Access database. The fewer steps it takes to get to done, the better. On the opposite end of the user spectrum, we have people who need isolated development environments. We know what we need and either know how to or can figure out how to get it. When your goal is to move product, what sense would it make to favor the latter over the former?

To all those involved in this thread, please do not take offense since this is not directed at you. Another very important thing to remember is that, in my (common) experience, most people who speak of computer security have no business doing so. Its a very messy world dominated by personal philosophy, misrepresentation, worst-case horror stories advice. Passers-by should either evaluate their own situations, or ask the advice of trusted professionals who have proven themselves to you in the past.

The fact that opening access to the entire host operating system's filesystem is potentially dangerous in the same way opening your front door is dangerous. It could be the pizza guy, or it could be a home invasion robber. There are plenty of facilities available to both Windows guest and OS X host to keep things safe, and those are the ownly two places where such things really need to be considered.

 

Where to do a thing and what thing to do was never in doubt. The questions are: Why has Parallels made me make this decison in the first place, and do I choose system security proactively by turning off the breach or retroactively by restoring lost files. That presumes that content is lost. Nothing you suggest tells me if files have been copied to a remote site and that can be worse than lost data if what was stolen was your turbotax database for the last 6 years that you thought was safe from Windows exploits because it was stored on in your Mac filespace. In your scenario with the pizza delivery guy or a robber you don't leave any option for a sicko that just wants to stick your toothbrush in his bum and leave quietly. That is the intruder you will never know was there but wish you did.

 

Uh, you CAN turn off Global Sharing. Turning it off will -- in your mind I guess -- make it so no one play with your toothbrush.

I think the issues have been "aired" enough.

 

So long as Parallels removes the following before stamping these features in a GA, none of this is really their concern.

Of course, the "no chance of infecting your Mac" is still correct.

 

Are you suggesting that it is impossible for a VM running an infected Windows session to install a malicious binary in your OS X home directory and add a line to your .profile or .bashrc that will execute it the next time you light off a terminal session? Seriously?

 

Let me state this very simply:

1) It is possible to implement drag and drop without exposing the host filesystem to programs on the guest.

2) If drag and drop is going to be provided, it should be done that way.

3) If it isn't, it's unsafe.

 

Numbers two and three are your opinions and are best stated in that fashion.

 

No. Only that Windows malware won't hurt Mac OS X.


Of course, this whole thing is quite silly. Unless networking is disabled, anything infecting the VM potentially has access to unprotected services on the VM's host or other hosts on the network.

But let's not debate having networking in virtual machines should be disabled by default, or the perils of address-based authentication.

 

Well said! Like I said before, a closed and a wide open approach isn't ideal. The best solution is restricted access to the host filesystem to minimize potential losses while enabling maximum functionality (drag and drop between guest vm and host os) at the same time. I don't see why this isn't ideal for everyone involved. For those who want to completely close off the sharing between the VM and the host os, they can be provided a switch to the feature off, but it shouldn't be off by default, though.

 

I too was very glad when "serv" from the development team weighed in on this matter. Because I found it hard to follow what was said, I have puzzled over it for a while. Here is what I have been able to glean from it. If the assembled intelligence here thinks there are errors in my interpretation, please offer your corrections:

1) In their effort to integrate the guest and host OS's, begun with Coherence, the team has been working on global drag and drop for some time.
2) They found a way to enable this feature without exposing the entire file system to the guest, but it was very slow, because it involved the writing of temporary files rather than direct transcription.
3) However, they were also aware that if they alerted users to the vulnerability that the direct method would cause, users would be concerned, and would turn this feature off.
4) Therefore, they decided to introduce this feature without mention of the downside, hide the toggle in an obscure preference pane, and turn it on by default.
5) They reasoned that if anyone did discover the problem and complained about it, they could cover themselves by a) accusing that person of windows bashing and paranoia, b) claiming that the increased risk was negligible anyway and c) pointing out that you could in fact close the hole by unselecting the preference. And if all that failed, they could always insist that any corruption was the user's fault for not having implemented proper virus protection, especially on the host side.

What makes this situation even more interesting is that VMWare had previously enabled global drag and drop in their public beta, well before the latest RC was released, but without opening the security hole--a fact of which Parallels' clever development team was no doubt aware. I suspect that this pushed Parallels to roll out this feature rather more quickly than they might otherwise have done, and before having figured out a fast but "sanitary" way to do so. But this latter is pure speculation on my part.

If I am correct, then Parallels is following a rather high risk, albeit cleverly conceived, strategy to try to capture as much of the Mac virtualization market as possible before VMWare can get a shipping product out the door. This strategy targets single users rather than large organizations, unlike VMware. So far, they are ahead by a nose. Whether they can prevail in the long term is an open question. But one must admire the sheer chutzpah.

 

That is different from what you quoted above. Of course it is easily possible for Windows malware to hurt the OS X environment in several ways ranging from denial of service (depleting file space), data harvesting the OS X file system, planting a binary in a writable directory and modifying the user's shell profiile to execute it. There are three different methods available now with three different purposes, and I don't even think of these things for a living. Imagine what a professional cracker could come up with. Now the only reason these three samples are even possible is because global sharing is on by default. Is there an exploit written to take advantage? Not yet, but I could have one finished by the end of the day, not that I would or have any interest in doing so. Now all that is needed is to exploit Windows - a nice new unpatched Win2K or XP installation should take about 10 minutes to crack.

Don't expect Aunt Vivian and Uncle Fred to understand any of this - their grand kids did the Parallels installation so they could use their favorite Windows chat proggy when they visit during Easter break.

The point being, no part of that statement you quoted from Parallels is true with an out of the box installation.

As for VM access to the host's unprotected services - no other VM I use or have used does this. Beginning with OS/2 running Windows or DOS in a VM to Solaris' containers to VMWare running on the Mac, Linux, and Windows - only Parallels out of the box gives my VM access to the host. Solaris containers kick butt, btw. Creating Sol 10 VMs within a Parallels VM is a fun little exercise.

 

I think the solution they found was a result of colliding philosophies between engineering and marketing where the clock is a common enemy. They are aware of the problems with this method, probably have other ways to do the job, but little time to deploy. It doesn't matter any longer that they were first to market in this market segment - the 800 lb gorilla in in the game now and that has to impact decisions and schedules. I don't think there is any conspiracy to deceive but I and others have strongly questioned the wisdom of this particular solution.

 

This post as well my previous one in this thread is my personal opinion not to be taken as official.

To joem:
My conspiracy theory note was about post 41 of the thread. Not a big deal if not provoked by the general tone of this thread. And "disgust for Windows" was pointing to dkp accusation of Windows being evil.
You have identified two problems with DnD via temp file: space and time pollution which are more noticeable on larger files. But there are more. And the "wormhole" approach you suggested (which was considered internally too) breaks quickly too. Here's a colorful little tale for you.
Mr. Stock Investor has just received some buing advice from his broker. He's a careful enough not to use Outlook in Windows VM because of its (alleged) insecurity, but he needs Excel to open the attached spreadsheet. Excel is handily running, so he just drags email attachment on Excel and laughs -- the "advice" is totally insane. Either his broker has lost his mind, or he hired some new blood. But since Mr. Investor was going to make his next bet anyway, he edits the .xls and even adds some good commentary, saves the file and sends it to broker for execution.
Next week when he gets his portfolio report he's shocked: the brokerage did not follow his orders but executed that stupid "advice" instead. Mr Investor quickly checks his outgoing email attachment only to find that he himself requested the execution of the "advice"! (at this point my Muse just came in) Mr. Investor silently takes out his trusty Colt from his old days and sprays his brains over the wall... Should the weapon requested his password in confirmation, he might have had a second thought on his spontaneous action. But whether he had the security feature disabled or it wasn't supported I don't know.
A few minutes later his 5 year old comes in, sees her father in his chair with seatbelts fasten tightly, takes the gun from his hand and goes out. The rest of the story is too gory to tell... In the end the disconsolate widow tries to sue computer software vendors. But she fails quickly because historically all software come without warranty express or implied. She ends up pushing the law of mandatory amputation of human hands on the grounds that it can operate a gun.

Seriously... I hope you take the whole thing easier than dkp does.

Your point on rebooting Mac after installation is well taken. Here's an answer. There's an OSX bug, preventing clean unload of ethernet interfaces in certain cases. This doesn't happen often, and not all users are affected, so requiring a reboot every time is an overkill. On the other hand standard OSX installer doesn't allow conditional reboot as far as I can tell. We ended up without. This issue is interfering with PD installer bug introduced after 2.2 (not exactly mine, but you can blame me anyway) that prevents proper setup of Host-Only and NAT interfaces. The second will be fixed in upcoming versions restoring world pace.

 

Serv:

I'm having trouble identifying where I said Windows was evil. I have acknowledged that it is the most hacked OS in history, but that makes me only the messenger, not the originator, of bad but very accurate news. Gentlemen don't shoot the messenger, particularly when the messenger is a paying customer. Implicit in my noting the hackability of Windows is the presumption it will continue to be hacked and that includes instances running in virtual machines. If you or anyone else at Parallels believes this to be untrue, please step forward. If you do allow that Windows running in a VM in Parallels can be hacked then you have to agree that the host OS is in jeopardy as well for users who do not understand the ramifications of global sharing.

You don't make me out to be unnecessarily alarmist and I won't make you out to be uncaring or lax about what many of us see as a significant and serious shredding of the sandbox paradigm touted in your brochures.

 

Too late -- you already did all of that. And the "sandbox" can be completely protected by disabling the features that you don't like.

 

Hi Serv,

Just a couple of comments: First, I don't think the wormhole approach breaks the way your example tries to indicate, at least for me, because I know that dragging and dropping an unknown file such as an email attachment between the environments is a risk.

What I'm talking about is exposing my file system, and particularly my home directory, which isn't protected by OSX permissions to malware running on the guest. Clearly, if I do something stupid (such as open a terminal prompt and do a sudo rm <whatever>) I can do some damage, but malware shouldn't be able to do that without my help.

So please consider implementing a requirement for proof of physical presence for drag and drop to work.

As to the reboot issue, if reboot is sometimes required, regardless of the reason, suggesting a reboot on install would at least save you some tech support cost once you get support organized, and would save users trouble. Installs are done infrequently, so even requiring a reboot would be low cost.

 

As a thought, for an alternative implementation:
Why not have a share on the guest full of hard-links to the files being worked on? When dragged the hard link could be created, then removed when the copy is complete. A hard-link on the OSX side removes the problems with multiple copies of files (as it is the same file) and also removes the potential security holes as you would not have links for every file on the Mac, and new links could only be created by Parallels on the Mac side...

 

Hard links don't work across partitions and introduce interesting ownership/permission issues and probably some operator confusion if you use unionFS.

 

Not to mention the possibility of malware authors discovering the hole and crafting hard links to probable files. A hard link, even if it would work, is still a hole. The gate needs to be a mouse click detected from the host. Nothing else (other than a keypress) will work. It has to be something that cannot be spoofed by code running on the guest. That is an absolute requirement for safety.

 

I think they've decided to go with mediocrity. Val should be pleased.