back to article RDP loves company: Kaspersky finds 37 security holes in VNC remote desktop software

VNC remote desktop software has no shortage of potentially serious memory-corruption vulnerabilities, you'll no doubt be shocked to hear. This is all according to [PDF] a team at Kaspersky Lab, which has uncovered and reported more than three dozen CVE-listed security holes, some allowing for remote code execution. VNC, or …

  1. Anonymous Coward
    Anonymous Coward

    TightVNC development is active AFAIK

    www.tightvnc.com/news.php

    Sourceforge news and files out of date, but bug tracker seems current:

    /sourceforge.net/p/vnc-tight/bugs/

    1. diodesign (Written by Reg staff) Silver badge

      Re: TightVNC development is active AFAIK

      Ah, the 1.x version is no longer supported and that's what Kaspersky studied. There is a version 2.x. I'll make this clearer in the piece.

      C.

      1. Doctor Syntax Silver badge

        Re: TightVNC development is active AFAIK

        This also needs the same clarification: "or migrating off, in the case of TightVNC".

      2. Robert Carnegie Silver badge

        Re: TightVNC development is active AFAIK

        It's implied that TightVNC 1.x has continued in use although unsupported. This must be partly because you have to pay (pay again ?) forTightVNC 2.x, which declares as not containing GPL program code and seems to be not covered by this testing. The question then... were users told that TightVNC 1 would be unsupported from date x, and were they told that before date x? Well... it's entirely credible, of course, that many users went on running the old product after they knew in good time that the guarantee of maintenance, such as it was, was withdrawn. However, when it was supported, evidently bugs were in it dating from 1999, the whole time.

        1. cheekybuddha

          Re: TightVNC development is active AFAIK

          From the TightVNC download page:

          [quote]Licensing Terms

          There are two licensing options available for TightVNC software:

          GNU General Public License version 2 (often abbreviated as GNU GPL). This is the default licensing option. It's completely free but it does not allow integration with closed-source products. Read the complete text of the license here (opens in a new window).

          Commercial source code license. Unlike GPL, it allows integrating the software into proprietary products, although it's not free.[/quote]

          So it seems you can use the latest 2.X version under GPL, only integrating with closed source software requires the commercial licence.

      3. Anonymous Coward
        Anonymous Coward

        Re: TightVNC development is active AFAIK

        From: https://www.tightvnc.com/download.php

        "Older Versions: If you need a version working in Windows 95/98/ME, Windows NT 4.0, or in Unix-like systems (including Linux), download TightVNC 1.3.10. "

        So it looks like if you are using it on linux, you will have to change to something else/

        1. bombastic bob Silver badge
          Meh

          Re: TightVNC development is active AFAIK

          So it looks like if you are using it on linux, you will have to change to something else

          oh, so THAT is what happened! [I don't use Win-10-nic and haven't VNC'd with a windows box in FOREVER... so that is probably why I had to switch to Tiger VNC for BSD and Linux - lack of current X11 support etc.]

          windows-only. THAT is @#$%^ *DISAPPOINTING*.

    2. bombastic bob Silver badge
      Linux

      Re: TightVNC development is active AFAIK

      I've been using Tiger Vnc which is a fork of TighVNC... because for quite a while it seemed out of date and wouldn't handle certain GLX things that Mate and other systems needed support for. So I switched.

      from the article:

      600,000 public-facing machines offer VNC access

      These people exposing "known port" VNC connections MUST understand it's a security risk already... what, does VNC protocol's pathetic password protection actually HELP? do ya think? yeah, should be obvious, right? I wonder how many OTHER firewall logs have shown a zillion daily attempts at banging on ports 5900-5999 looking for VNC...

      (they should be using a VPN and ONLY listen on private addresses at the very least and NOT exposing those ports to 'teh intarwebs')

      But then again, WINDOWS machines are INFAMOUS for "listen on *.*.*.*" so there you have it. Unless you explicitly put a firewall between 'teh intarwebs' and your windows boxen, you're insecure (apparently) by DESIGN.

      Sure, putting ANY windows on a public IP is just STUPID these days. So, at least firewall it with a LINUX box, at the VERY least! [you could even use an RPi to do it if you add a 2nd network adaptor or make it a WiFi access point]

      And when you need VNC access from 'teh intarwebs' you should use a VPN or ssh anyway. It's just common sense.

  2. Anonymous Coward
    Anonymous Coward

    KVM

    I wonder if this could also be problematic for users running virtual machines?

    I know that Wireshark shows VNC connections to lo/127.0.0.1 when running a virtual machine using KVM/Qemu for the gui.

    1. bombastic bob Silver badge
      Devil

      Re: KVM

      VNC into a KVM seems to work ok for me and I've used it a LOT actually... but usually by setting up an ssh tunnel so I'm listening on a specific IP address [usually localhost] on whatever machine I want to access it from. To make that work you can have a headless (Linux or BSD) VM that makes an ssh connection onto another machine (let's say a server) and directs incoming "server:xxxx" to "vm:22" for ssh. Then, just do something like "ssh server xxxx" to access it. That's how I've been doing it, anyway.

      THEN, for VNC access, you use something _like_ TigerVNC server to actually run the desktop, and set up VNC tunneling via the ssh connection [same basic idea] and VOILA! you open VNC and you now have the full desktop. (you can also do this on an RPi that's headless to access its desktop via VNC).

      This works exceptionally well when you want to have KDE on your Mate machine, or if you want to do X11 debugging from a GUI [so you run the debugged program in a VNC session, which is a different X server and isnt going to lock up on you if you break in the middle of certain libX11 calls...].

      Anyway, ssh + sshd tunneling magic works fine. A bit tricky at first, but there are many examples in duck-duck-go-land

      1. pLu

        Re: KVM

        VNC clients like Remmina let you configure an optional SSH tunnel.

  3. man_iii

    VNC isn't secure!

    News at 11 ... Vnc isn't secure. Use it over SSH or some encrypted tunnel... Common sense I would have thunk it was.... Vnc does its job and not meant to be your secure piece of code.

    1. robidy

      Re: VNC isn't secure!

      Later news at 13.37 commtard found not reading article.

    2. Jou (Mxyzptlk)

      Re: VNC isn't secure!

      It can be secure, using SSL/TLS builtin. But if you want to stick with a VNC implementation which doesn't: Use your stunnel, if you need.

      1. bombastic bob Silver badge
        Meh

        Re: VNC isn't secure!

        I'd still do the tunnel. It's been my experience that things _like_ VNC aren't trustworthy enough on their own, and it would just be simpler if you always use them via SSH and NEVER expose their ports to 'teh intarwebs'. It's kinda like "safe surfing". No amount of anti-virus or similar things will stop the daily pounding on the expose ports, nor prevent a 0-day exploit. Use SSH and firewall it.

  4. Doctor Syntax Silver badge

    "RealVNC forbids reverse engineering"

    OTOH if you're one of the bad guys this won't put you off and you won't be raising CVEs about it. For the rest of us any of the others seem a better bet - they're open to feedback like this from 3rd party checking.

  5. Dwarf Silver badge

    If RealVNC prevents reverse engineering, then what happens if the vulnerabilities found in the others are tested against RealVNC as a black-box test. This will give a view as to if its better by not having those vulnerabilities or just hiding behind a pretend wall. I know where my money is on this one.

    Even if not all the vulnerabilities detected in the others can be tested from the outside, a sample of n that give correlation to the others will help in giving a view of the likely risk

    Alternately, and the far easier option. Dump RealVNC and go for something else given that the security can't be independently verified and remote console access is kind'a important from a security perspective.

  6. Jou (Mxyzptlk)

    My reason for RealVNC 5.x

    RealVNC: Has TLS encryption built-in for MANY years including certificate handling and automatic certificate generation upon installation. And I am used to its good usability.

    UltraVNC: Whoa, still hackish encryption plugin hell! No improvement since Windows 98... https://www.uvnc.com/downloads/encryption-plugins.html

    TightVNC: What is encrpytion? Oh, planned for future, maybe https://www.tightvnc.com/faq.php#howsecure

    TigerVNC: A Spinoff of TightVNC with TLS, actually looking good! But requires external certificate tools (avail in every OS) for more than "Anonymous TLS", which requires more work, but still looking good for a free program - sadly not tested by them?

    TurboVNC: Huh? For Windows ONLY the viewer? Though they have encryption, but I couldn't check for obvious reasons ;).

    1. This post has been deleted by its author

    2. bombastic bob Silver badge
      Devil

      Re: My reason for RealVNC 5.x

      TigerVNC: A Spinoff of TightVNC with TLS, actually looking good!

      and generally, TigerVNC has better support for X11, such as GLX support, something that Mate (and apparently gtk3 in general) needs. It's why I switched to it a couple o' years ago, yeah.

      I haven't tried the TLS though. And yeah self-signed certs with openssl are built-in except Windows, but I'd just use Cygwin or a Linux or BSD box to generate them for W, so there ya go.

      But even with TLS I'd rather firewall it. Mentioned already, the daily poundings on VNC's listening port range by automated crack-bots makes it NOT worth having attached to teh intarwebs'. SSH login attempts are bad enough [but fail2ban helps with that, yeah]

      1. phuzz Silver badge

        Re: My reason for RealVNC 5.x

        I've found x11vnc works pretty well on Mint MATE, might be worth a look Bob.

    3. phuzz Silver badge
      Stop

      Re: My reason for RealVNC 5.x

      Friends don't let friends expose VNC to the public internet.

      Use a VPN or an ssh tunnel or something like that. (Unless you're building a honeypot.)

  7. cheekybuddha

    Shame that x11vnc wasn't also included in the tests

  8. aldolo

    i used vnc to check my home webcam. the server keep locking within minutes because of so many accesses with the default password. vnc is definitely widely targeted.

    1. bombastic bob Silver badge
      Thumb Up

      the server keep locking within minutes because of so many accesses with the default password.

      Yep, that's consistent with my observations as well, DECADES AGO even. FIREWALL NEEDED.

    2. Anonymous Coward
      Anonymous Coward

      While VNC and RDP offer encryption, VNC offers no real AAA solution and RDP typically will be to an environment where it doesn't utilise a centralised AAA system if one is in-place (i.e. local accounts on one hosts versus AD).

      Instead, use one of the many free or commercial VPN options as your transport layer with RDP/VNC over that.

      My personal preference is to also use the VPN option for SSH - while SSH can be correctly configured (i.e. no root access, use sudo, use SSH keys instead of passwords), the flexibility of most VPN solutions and the ability of some server "owners" to do silly things in-spite of best endeavours and configuration management systems means standardising for all admin access to hosts via VPN saves a lot of pain in the long term.

  9. HxBro

    What about macs ? Remote desktop is based on vnc

    Any testing against the mac server ?

  10. nekomoto

    What constitutes a rish though

    There used to be a version of a C compiler which would flag any use of a old-style C string function as a flaw / risk, even something like:

    char block[20];

    strcpy( block, "foo" ); /* safe because "foo" can always fit in 20 bytes */

    Obviously "foo" can never be larger than the target buffer, so it's not possible to be a source of problems.

    I wonder how much of their analysis simply counts these sorts of function calls in the code, without actually investigating whether it's a genuine problematic use or not.

    1. ovation1357

      Re: What constitutes a rish though

      The trouble is that the char declaration is likely to be made in a header file or at least not right next to the assignment of its value so whilst the initial code is 'safe' because it fits, it isn't future proof because another developer may be tasked with changing 'foo' to a much longer string, or perhaps to accept it from a config file or user input. That is the the point at which someone inadvertently introduces a serious security bug.

      By adopting a coding standard of only permitting safe functions to be used in your code goes a long way to mitigate against this.

      So I do see your point that this kind of thing could be called out as a security problem when it's currently not exploitable, but actually one could argue that bad coding practice is bad security practice and should be nipped in the bud.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019