Who controls the remote control?

Would you click on allow?

http://krebsonsecurity.com/2012/03/aghast-at-avasts-iyogi-support/

The original story is about exploiting free product support by trying to sell premium support on non-existent issues.
Would you allow a complete stranger full control over your PC?

I've made some tests myself with two of the most prominent remote support offering: WebEx and Teamviewer.
WebEx does not allow unattended download of files: each file should be explicitly shared by the owner.
Teamviewer, instead, allows full filesystem access, and a file transfer request from the controlling end, opens a notification window on the remote side with full logging. Sadly that window can be minimized and can be easily ignored by a less expert user.

I'm not saying here that Teamviewer GmbH will exploit your computer, but there's a chance that someone using it, could.

So much for the corporate level support, but there is a whole market for personal connectivity.
I was browsing the appstore for an RDP/VNC app to control my PC, and I saw that there are plenty. Some of them even require you to install an host component on the target PC. Apparently this trend has been fueled by Microsoft, by disabling Remote Desktop on the Home edition of the latest Windows versions.
What kind of guarantee the user has that the host and the remote app don't do anything suspicious?
Most of them, don't even connect directly the client to the server, but use some kind of external gateway, to overcome NAT issues.
This a classic man-in-the-middle scheme.
Do you trust their encryption?
Do they keep a copy of your remote control session?
Nearly all of this remote control apps have file transfer capabilities:
Once you have given full access to your pc, how much it takes for the "man-in-the-middle" to download browser history, password cache, "My Documents" folder?

So, by looking at my cristal ball, I may say that the next wave of phishing malware will come in the form of free remote control tools.

Xvnc black screen

I was configuring my workstation for remote VNC login following this blog post.
The checklist ends suggesting a reboot command.
If you don't obey, you'll only get a black screen on a VNC connection.
That seems to break the spell: no reboots under linux!

After some investigation it seems that the cause was gdm not accepting tcp connections from Xvnc.
A full reboot is not necessary, just a gdm restart:

Find the gdm instance started by init:

# ps -ef --forest

search the process tree for something like this:

root      3621     1  0 14:35 ?        00:00:00 /usr/sbin/gdm-binary -nodaemon

root      3707  3621  0 14:35 ?        00:00:00  \_ /usr/sbin/gdm-binary -nodaemon

root      3713  3707  0 14:35 tty7     00:00:00      \_ /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7

gdm       3734  3707  0 14:35 ?        00:00:00      \_ /usr/libexec/gdmgreeter

the parent gdm here has PID 3621

# kill -1 3621

The console X session will restart, and after that, VNC logins will work.

Update:
On RHEL/CentOS 6, you must use kill -9 to reload gdm, and the vnc-server package is called tigervnc-server