vino establishes a HTTP connection to check connectivity

Thanks for opening this bug, but how exactly would NetworkManager know if an _incoming_ port is open or not?

This came about because a user wanted to VNC to a machine which is inside a LAN that has no connection to the outside world. In that instance vino refused to enable because it couldn't get to the outside world to test the incoming port. So using an external site to detect local connectivity isn't robust.

I see three issues really.

1) vino shouldn't depend on an _internet_ connection, but could just rely on a _network_ connection, in which case the suggestion jpds makes about nm seems valid? Many (most?) people will be behind NATed connections so an external site making an inbound connection to VNC server will be pointless because without port-forwarding it will always fail.

2) vino shouldn't rely on some random website(s) to determine if it should or should not start.

3) The user is not told (or asked to confirm) that an outbound connection, and a subsequent inbound connection to their machine is made.

This bug seems to be a combination of those issues.

1) vino doesn't use the external website to check for connectivity. Even when the remote website isn't accessible, vino is still supposed to start up fine. It only uses the remote website to determine if the computer is accessible from the internet so it will display an appropriate message to the user. Even if the user is behind a NAT connection, vino has an option to use uPnP to reconfigure the user's firewall to forward the appropriate port.

2) It doesn't. Please give exact steps how to reproduce this issue, as it works fine for me when I block outgoing connections.

3) This is no different than ntp connecting to a remote website to sync the time when the machine is booted, or firefox connecting to a remote website when it is opened to check if new plugins are available. I don't consider this a security issue.

So, if you don't have network connectivity, and you uncheck the box and check it again, the setup tool will hang for around 30 seconds waiting for the remote server to respond. This could be better.

I will attempt to reproduce the connectivity issue, but accept it may well just be a lack of patience, not waiting long enough for the time out.

I don't believe it's the same as ntp. With ntp the hits go to Canonical controlled ntp servers by default. Firefox checks for updates at Mozilla corporation servers?

Vino goes one of two (randomly selected) hosts which are out of the control of Canonical or upstream corporate entities. Would Canonical corporate desktop customers be happy about the existence of Ubuntu machines 'leaking' out to 3rd party sites?

I was unable to find any terms of service or a privacy policy at the URLs specified in capplet/webservices including:-

http://blog.jorgepereira.com.br/jorge/org.gnome.vino.Service.php
http://blog.jorgepereira.com.br/jorge/
http://blog.jorgepereira.com.br/
http://jorgepereira.com.br/
http://www.bani.com.br/vino/vino.php
http://www.bani.com.br/vino/

At the following URL I discovered the upstream maintainer of vino

http://www.bani.com.br/

No reference to terms of service or privacy policy regarding vino is made on any of those pages. How do I know what they are doing with the data sent to them by the vino-preferences applet?

Indeed switching on the VNC service immediately makes me vulnerable to attack by announcing to those two sites that I have a VNC server running at my IP.

If either of those domains expired, or were hacked then that could compromise the privacy and security of my desktop surely? Whilst I appreciate the same could be said of the *.ubuntu.com domains and *.mozilla.com domains, I place more 'trust' (perhaps wrongly) in Canonical and the Mozilla foundation than I do in two blogs run by individuals.

It should be noted that I'm not casting any aspersions on the owners of those two blogs or their maintainer-ship of the vino project. I am just uneasy about the remote call made without my consent or knowledge.

Hi Marc, I am the original user. Thanks to Alan for filing the bug report. I'll clarify a couple of things. The machine (running Ubuntu 9.04) is on a typical domestic 192.168.1.x network, and *does* have internet access via a typical domestic Comtrend router. The router is not configured to forward any ports, nor do I want it to be.

Using the GUI too, after making the internet check, it displays "Your desktop is only reachable over the local network. Others can access your computer using the address localhost".

Perhaps slightly atypically, I have given it a static IP address; in doing so I seem to have got network manager thoroughly confused. It's a laptop in a docking station so it has two wired ethernet interfaces and one wireless.

Despite ifconfig showing a valid interface:
eth1 Link encap:Ethernet HWaddr 00:06:xxxxxxxxx
          inet addr:192.168.xxxxxxxx
(and so on) and having full normal internet access, network manager lists the wired interface that I am using as being "not managed" and that therefore (as far as it's concerned) there is no network connection at all, as the other two are currently unused.

So I've commented out the entries in /etc/network/interfaces setting up a static IP and gone back to a DHCP address and full management from Network Manager. But it's still coming up with the message about "localhost" and there's still no listening port or process listed in "netstat -nap".

I'm guessing the issue here is something to do with Network Manager getting in a muddle about what is up and running, and vino using bad information from Network Manager. As I said, it's a laptop, and with the wireless interface sometimes appearing as eth1 and sometimes as eth2, depending on whether it was plugged into the docking station, things seemed to get very confused.

As regards the outbound network connection issue: it is not clear at all (even to someone that's been using both VNC and Ubuntu for years! (just not the built-in server)) that "vino-preferences" is legitimate, nor is it clear at all that the IP it connects to is legitimate.

Alan,

your comment went in while I was writing the above. Hope it's cleared things up a bit. There seem to be two issues here with Network Manager:
1. It doesn't play nicely with hard-coded interfaces in /etc/network/interfaces
2. If eth1 (for example) gets reassigned from a wired interface to a wireless one and back again, with the user (me) switching from static Ip to DHCP and back again, it starts to get in a mess.

With reference to security, a further point is that some of us frequently set up VNC with very weak passwords *when* it is assumed that only connections from the LAN will be made and the outside world is not going to have access. The checkbox labelled "configure network automatically to accept connections" is not clear at *all* [1] that it will try to configure the *router* to open up access to the outside world. Only in the tooltip - easily missed - does it mention the router. *My* assumption was that this checkbox referred to something on the local machine's networking. The upshot is that this *could* lead to someone setting a weak password and then opening themselves up to the world.

The attempt to establish whether access from the outside world is possible is not in itself a bad idea - far from it! - but it should be clearer what's going on and it should connect to something like vnc-test.ubuntu.org. IMO, etc.

[1] it's also badly phrased, perhaps in a mis-guided attempt to avoid a split infinitive. Is it "automatically configure network to accept connections" or "configure network to automatically accept connections"?

Unmarking as security. This password is not sent in the clear with the RFB protocol, so its strength doesn't matter (though, the protocol is not considered secure, so tunnel over ssh or VPN if need a secure solution).

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

$ cat /usr/share/vino/webservices
# This file lists all webservices URLs that can be used by vino to provide
# a connectivity test.

Comment out the http's:

# Jonh Wendell
http://www.bani.com.br/vino/vino.php
and
# Jonh Wendell
http://www.bani.com.br/vino/vino.php

and add:

http://localhost

Note: if you don't have anything there, vino-server goes into max cpu
mode until you kill it.

Yesterday I found this in my log:

Aug 1 12:39:33 len IN= OUT=eth1 MAC= SRC=192.168.0.107 DST=189.38.80.51 LEN=60 TOS=10 PREC=0x00 TTL=64 ID=43445 CE DF PROTO=TCP SPT=39385 DPT=22 SEQ=3475551532 ACK=0 WINDOW=5840 SYN URGP=0

This 189.38.80.51 maps back to kamotini.kinghost.net but is also the address for blog.jorgepereira.com.br, which is listed in /usr/share/vino/webservices.

Guys & girls, this is unacceptable. vino must not contact any random webservices w/o asking the user first. No matter how trusted these webservices are supposed to be or that "no sensitive information will be transferred". Please reconsider and disable these "services" ASAP until a viable solution is found to let "NetworkManager know if an _incoming_ port is open or not".

Thanks,
C.

That message and port access check is dropped in Oneiric, so I'll mark this Fix Released.

Will this be fixed in 10.04 (LTS!) too?

I see it got unmarked as a security bug. If I may try to re-explain why I think it *is* a bug. Firstly, many VNC users set very weak passwords (e.g. 'password') because they are using it internally behind a firewall, and anyone with physical access to one machine has physical access to the other (or is a trusted family member, etc.).

Secondly, the phrasing "configure network automatically to accept connections" is *so* poor that a user could very easily take it to mean "configure this machine's network interface to accept connections automatically", i.e. a desired behaviour.

Taken together, this could easily lead to users exposing a VNS interface with a weak password to the world, making them vulnerable to brute-force IP scanning attacks.

Dom,

Those two points (the first being user error) have nothing to do with this bug report, which is about vino connecting to an external server to check its network connectivity. Please file a separate bug report about these if you wish to.

Christian,

While I agree that it is unfortunate that vino tries to speak to an external website to verify if vnc is properly available, there is currently no plan to apply these changes to other releases than Oneiric.

Please see https://wiki.ubuntu.com/StableReleaseUpdates if you would like to propose an SRU.

You can also see the comments above for workarounds.

This is still happening with 3.5.2-0ubuntu1 on Quantal which I confirmed via tcpdump whilst enabling and disabling remote control in vino-preferences.

189.38.80.51 is the host used by http://blog.jorgepereira.com.br/jorge/org.gnome.vino.Service.php

alan@deep-thought:~$ host blog.jorgepereira.com.br
blog.jorgepereira.com.br has address 189.38.80.51

alan@deep-thought:~$ sudo tcpdump -v dst host 189.38.80.51
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:42:10.753010 IP (tos 0x0, ttl 64, id 535, offset 0, flags [DF], proto TCP (6), length 60)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [S], cksum 0x58fd (incorrect -> 0xffed), seq 3623359539, win 14600, options [mss 1460,sackOK,TS val 923172 ecr 0,nop,wscale 7], length 0
09:42:10.997592 IP (tos 0x0, ttl 64, id 536, offset 0, flags [DF], proto TCP (6), length 40)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [.], cksum 0x58e9 (incorrect -> 0x7093), ack 4276424314, win 14600, length 0
09:42:10.997781 IP (tos 0x0, ttl 64, id 537, offset 0, flags [DF], proto TCP (6), length 192)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [P.], cksum 0x0bd0 (correct), seq 0:152, ack 1, win 14600, length 152
09:42:11.242896 IP (tos 0x0, ttl 64, id 538, offset 0, flags [DF], proto TCP (6), length 260)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [P.], cksum 0x189c (correct), seq 152:372, ack 1, win 14600, length 220
09:42:17.494771 IP (tos 0x0, ttl 64, id 539, offset 0, flags [DF], proto TCP (6), length 40)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [.], cksum 0x58e9 (incorrect -> 0x67ef), ack 686, win 15755, length 0
09:42:20.535237 IP (tos 0x0, ttl 64, id 540, offset 0, flags [DF], proto TCP (6), length 40)
    deep-thought.local.45965 > kamotini.kinghost.net.http: Flags [.], cksum 0x58e9 (incorrect -> 0x67ee), ack 687, win 15755, length 0

Hey Mathieu, could you look at that again?

So the issue was that updating the message once the check responds was indeed disabled upstream, but the check was still being done -- I'll fix this by disabling that webservices check altogether, since it's not giving any benefits as it is now and the underlying IPv4/IPv6 connectivity issue hasn't yet been resolved.

This bug was fixed in the package vino - 3.5.2-0ubuntu2

---------------
vino (3.5.2-0ubuntu2) quantal; urgency=low

  * debian/patches/disable_webservices_check.patch: really disable the
    connectivity check using webservices: the resulting message update was
    already disabled upstream, but vino was still silently sending the requests.
    (LP: #608701)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 21 Jun 2012 11:40:29 -0400

Alan, don't forget that there are two http links in the file:

bani.com.br needs to be blocked/commented out as well:
# Jorge Pereira
# http://blog.jorgepereira.com.br/jorge/org.gnome.vino.Service.php

# Jonh Wendell
# http://www.bani.com.br/vino/vino.php
 http://localhost

Add http://localhost

$ host bani.com.br
bani.com.br has address 69.163.151.181
bani.com.br mail is handled by 0 fltr-in2.mail.dreamhost.com.
bani.com.br mail is handled by 0 fltr-in1.mail.dreamhost.com.

$ host mail.dreamhost.com
mail.dreamhost.com has address 208.113.200.129

$ sudo tcpdump -vi wlan0 dst host 69.163.151.181
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
...
09:26:32.746029 IP (tos 0x0, ttl 64, id 356, offset 0, flags [DF], proto TCP (6), length 140)
    gg-laptop.local.40043 > apache2-emu.penguins.dreamhost.com.www: Flags [P.], cksum 0x1e53 (correct), seq 0:100, ack 1, win 115, length 100
09:26:32.770090 IP (tos 0x0, ttl 64, id 357, offset 0, flags [DF], proto TCP (6), length 260)
    gg-laptop.local.40043 > apache2-emu.penguins.dreamhost.com.www: Flags [P.], cksum 0xc495 (correct), seq 100:320, ack 1, win 115, length 220
09:26:32.798541 IP (tos 0x0, ttl 64, id 358, offset 0, flags [DF], proto TCP (6), length 40)

vino (3.4.2-0ubuntu1.1) is in the Precise queue waiting to be accepted by the SRU team.

Hello Jonathan, or anyone else affected,

Accepted vino into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/vino/3.4.2-0ubuntu1.1 in a few hours and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

confirming the bug before the update and that it's fixed with the new version

This bug was fixed in the package vino - 3.4.2-0ubuntu1.1

---------------
vino (3.4.2-0ubuntu1.1) precise-proposed; urgency=low

  * debian/patches/disable_webservices_check.patch: really disable the
    connectivity check using webservices: the resulting message update was
    already disabled upstream, but vino was still silently sending the requests.
    (LP: #608701)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 21 Jun 2012 12:00:06 -0400