vino establishes a HTTP connection to check connectivity

Bug #608701 reported by Jonathan Davies on 2010-07-22
This bug affects 5 people
Affects Status Importance Assigned to Milestone
vino (Ubuntu)
Mathieu Trudel-Lapierre

Bug Description

Binary package hint: vino

Vino currently sends HTTP requests to external webservices in order to attempt to determine outside reachability of the remote desktop service. Such tests were intended to display a result to the user, but the message update was disabled upstream (and has been for a little while). Unfortunately, the request to the webservices were not fully disabled, which may lead users to believe there are security issues with vino from the unwanted, unexplained traffic.

The proposed patch fixes the issue by completely disabling the webservices connectivity checks.

[Test Case]
1) Start tcpdump (preferably on a system that hasn't a browser open at the time):
sudo tcpdump -i any tcp port 80
2) Start vino-preferences
3) Observe that there is:
  a) with the original package: traffic being sent/received from or another such web service.
  b) with the proposed package: no traffic being sent/received.

[Regression Potential]
Minimal to non-existent. Removing a feature that is not currently user-visible, already partially disabled (i.e. totally disabled in the UI). The connectivity check in its current form remains because it was not completely disabled in UI, just the resulting message update was. (The test is done but the result is only used to be shown to the user, except that UI update was dropped upstream).

When enabling the VNC server in System β†’ Preferences β†’ Remote Desktop, Vino establishes an HTTP connect to an external website to check if connectivity is able:

[pid 5841] connect(17, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in progress) - defines the URLs to use to check connectivity while:


Appears to establish the connection. This is sub-optimal and something such as querying NetworkManager over D-Bus should be used instead.

Marc Deslauriers (mdeslaur) wrote :

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.

Marc Deslauriers (mdeslaur) wrote :

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.

visibility: private → public
Marc Deslauriers (mdeslaur) wrote :

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.

Changed in vino (Ubuntu):
status: New → Confirmed

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:-

At the following URL I discovered the upstream maintainer of vino

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 * domains and * 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.

Dom Latter (bugs-launchpad-net) wrote :

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.

Dom Latter (bugs-launchpad-net) wrote :


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 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"?

Jamie Strandboge (jdstrand) wrote :

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).

security vulnerability: yes → no
Sebastien Bacher (seb128) wrote :

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 (

Changed in vino (Ubuntu):
importance: Undecided → Low
NoOp (glgxg) wrote :

$ 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
# Jonh Wendell

and add:


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

Christian Kujau (christiank) wrote :

Yesterday I found this in my log:

Aug 1 12:39:33 len IN= OUT=eth1 MAC= SRC= DST= 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 maps back to but is also the address for, 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".


Changed in vino (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)

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

Changed in vino (Ubuntu):
status: Confirmed → Fix Released
Christian Kujau (christiank) wrote :

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.

Jonathan Davies (jpds) wrote :


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.


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 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. is the host used by

alan@deep-thought:~$ host has address

alan@deep-thought:~$ sudo tcpdump -v dst host
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 > 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 > 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 > 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 > 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 > 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 > Flags [.], cksum 0x58e9 (incorrect -> 0x67ee), ack 687, win 15755, length 0

Changed in vino (Ubuntu):
status: Fix Released → Triaged
Sebastien Bacher (seb128) wrote :

Hey Mathieu, could you look at that again?

Changed in vino (Ubuntu Precise):
importance: Undecided → High
milestone: none → ubuntu-12.04.1
status: New → Triaged
Changed in vino (Ubuntu):
importance: Low → High

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.

Changed in vino (Ubuntu):
status: Triaged → In Progress
Changed in vino (Ubuntu Precise):
status: Triaged → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in vino (Ubuntu):
status: In Progress → Fix Released
NoOp (glgxg) wrote :

Alan, don't forget that there are two http links in the file: needs to be blocked/commented out as well:
# Jorge Pereira

# Jonh Wendell

Add http://localhost

$ host has address mail is handled by 0 mail is handled by 0

$ host has address

$ sudo tcpdump -vi wlan0 dst host
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 > 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 > 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.

Changed in vino (Ubuntu Precise):
assignee: Mathieu Trudel-Lapierre (mathieu-tl) → nobody

Hello Jonathan, or anyone else affected,

Accepted vino into precise-proposed. The package will build now and be available at in a few hours and then in the -proposed repository. Please help us by testing this new package. See 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 . Thank you in advance!

Changed in vino (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Sebastien Bacher (seb128) wrote :

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

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

Changed in vino (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers