Bug 553477 (CVE-2011-1164)

My assumption is that the Assigned To here is either,
1. Deceased, or
2. Not interested.

Or,
3. Assigned To is busy, and has other priorities!

My apologies for the earlier remark - I have bugs with no activity for months and assumed otherwise. But I see updates by sandmann as recently as 2010-08-24 09:11:27 EDT.

I'll try to help by marking duplicates. Sorry for the noise.

This might be considered a security bug. If my VNC server is accessible from the public Internet but I'm being told that it's only available to the local network, that's quite a serious bug -- it might lead to me leaving it passwordless or leaving it enabled when I wouldn't otherwise.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still happening in Fedora 14.

I have real public IPv4 and IPv6 addresses, yet vino-preferences tells me "Your desktop is only reachable over the local network.".

Perhaps this is related to this upstream bug:
https://bugzilla.gnome.org/show_bug.cgi?id=596190

Partly, perhaps — but this isn't just about IPv6. These machines have public Legacy IP addresses too, and it *still* tells me:

"Your desktop is only reachable over the local network. Others can access your
computer using the address 90.155.92.250 or macbook.local."

Ah, I cannot reproduce that specific error right now — that was a cut and paste from above. The problem with Legacy IP addresses now seems to be that it'll pick *one* of the system's addresses, seemingly at random, and analyse that.

So if it picks my public IP address (for this F14 machine) 90.155.92.217 it *does* manage to give a vaguely coherent response, albeit with a broken reverse DNS lookup:
"Others can access your computer using the address 90.155.92.217 or i7.local."

But it's equally likely to pick one of the virt-manager bridges and instead tell me:

"Your desktop is only reachable over the local network. Others can access your computer using the address 172.31.0.1 or i7.local."

So the bug has changed form a little.

On RHEL6, it indicates that it is only reachable on the local network (using 192.168.250.141 or odvrhel6.local).   netstat shows me vino is listening to all interfaces.

If I look at the UPnP status on my firewall (pfSense) I see plenty of stuff, but nothing for port 5900 and nothing pointing to the IP address of this machine, so it is correct when it says local network and prints the local IP address.  Of course, if this is a direct connection to the internet and it were to report the same thing, then that would be misinformation.

The problem here is that this is a static string, that is translated:


vino-2.28.1% grep -r 'only reachable over the' *
capplet/vino-preferences.c:  message = g_string_new (_("Your desktop is only reachable over the local network."));
po/eu.po:msgid "Your desktop is only reachable over the local network."

And poking around in the error_message() function in vino-preferences.c tells me that it will _always_ say that, whether it's true or not.

Looking in the "Security" section, there is a "Configure network automatically to accept connections".  Once this is enabled, and if the local iptables rules allow incoming connections to port 5900 _then_ I see the change to UPnP on the firewall.

I'm not sure we can call it a security flaw when there are a few things that need to be done (and the issue is the fact that the word "only" is present (i.e. "Your desktop is reachable over the local network" is a whole lot different than when the word "only" is there).

1) You have to enable vino
2) You have to either disable iptables (on by default) or open port 5900
3) You have to tell it to configure the network automatically to get the UPnP support

(the last is only if you are behind a firewall, of course).

If all of these things were done for you without you knowing about it, I might agree with this being a security flaw, but there are some pretty deliberate steps that are required first.

As an aside, I also went back to look at Red Hat Enterprise Linux 5, but this is not an issue there.  vino-preferences simply says "Users can view your desktop using this command: vncviewer odvrhel5.annvix.ca:0".  That version of Vino also has no UPnP support.

Upstream does not plan on correcting strings or documentation until GNOME 3.0 is completed.  The root of this problem is not how vino operates, but the feedback that vino provides when certain options are selected.

Statement:

This issue did not affect the version of vino as shipped with Red Hat Enterprise Linux 4 or 5 as they did not include support for Universal Plug and Play (UPnP).  A future update in Red Hat Enterprise Linux 6 may address this flaw.  To mitigate this issue, users should ensure that confirmation is requested on each inbound connection attempt, that a password is required to connect, and that automatic network configuration is disabled.  This will prevent vino from using UPnP to allow access to the VNC port, and will ensure that any connections require a password and that the user is notified on any connection attempts.

I don't understand why there's any talk of uPNP here. There is no uPNP in the setup against which I filed this bug. The machine has a public IP address, and I still get the bogus message.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2013:0169 https://rhn.redhat.com/errata/RHSA-2013-0169.html