Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday November 23 2019, @11:17AM   Printer-friendly [Skip to comment(s)]
from the it's-checkers-all-the-way-down dept.

RDP Loves Company: Kaspersky Finds 37 Security Holes in VNC Remote Desktop Software:

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 Virtual Network Computing, is an open protocol used to remotely access and administer systems. Much like with the BlueKeep flaw in Microsoft's RDP service, miscreants can exploit these holes in VNC to potentially commandeer internet or network-facing computers.

Kaspersky says that, based on its best estimates from Shodan searches, about 600,000 public-facing machines offer VNC access as do around a third of industrial control devices.

"According to our estimates, [more] ICS vendors implement remote administration tools for their products based on VNC rather than any other system," said Kaspersky researcher Pavel Cheremushkin earlier today. "This made an analysis of VNC security a high-priority task for us."

[...] The investigation kicked up a total of 37 CVE-listed memory corruption flaws: 10 in LibVNC, four in TightVNC, one in TurboVNC, and 22 in UltraVNC. All have now been patched, save for the bugs in TightVNC 1.x which were present in a no-longer supported version: you should be using version 2.x anyway.

[...] Admins can protect themselves from RDP and VNC exploitation by updating their software (or migrating off, in the case of TightVNC) and using network filters to lock down access.

Who's in control?


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Disagree) by Mojibake Tengu on Saturday November 23 2019, @01:45PM (5 children)

    by Mojibake Tengu (8598) on Saturday November 23 2019, @01:45PM (#923818) Journal

    No personal responsibility in software is a wide road to disaster and collapse of whole digital civilization.

    For centuries, in civil engineering, machine-building, electrical engineering, metallurgy, chemistry, industrial people are personally responsible for their designs and actions, often lost careers or went to jail when negligence was too costly in damages or lives. Contrary to that, in software, incompetence and negligence is highly tolerable. It is a cultural problem, not technical. This negligence stems in lack of self-control, inherited from the initial culture of freaks and reinforced by their drug abusing. That brings a veil of plausibility for another layer, malevolent actions. State actors well know this and use this ably. Many critical open source projects managed by communities are infested by intelligence operatives, not just corporations. For decades.

    Current dogma of "keep up with software updates" is an insufficient strategy to mitigate, because when a backdoor is discovered and publicized, a corrupted author(s) just introduce(s) another one elsewhere, often very soon.
    Without possibility of legal punishment nor social ostrakization, he risk nothing and whole digital culture tolerates such behavior as an unavoidable necessity.
    Statistically, total amount of exploitable vulnerabilities still grows up.
    One day, it may reach the breaking point, a moment when all the software infrastructure of the world will collapse in one spectacular event by a chain reaction.

    We need to know. To find and collect real names of the backdoor vulnerability authors. For better future.
    We can and should do that with open source, at least. With public repositories, we can do that retroactively.

    --
    The edge of 太玄 cannot be defined, for it is beyond every aspect of design
    • (Score: 0) by Anonymous Coward on Saturday November 23 2019, @02:12PM (1 child)

      by Anonymous Coward on Saturday November 23 2019, @02:12PM (#923824)

      For centuries, in civil engineering, machine-building, electrical engineering, metallurgy, chemistry, industrial people are personally responsible for their designs and actions, often lost careers or went to jail when negligence was too costly in damages or lives.

      And for centuries before that, structures failed, see https://weburbanist.com/2014/04/16/ancient-engineering-fail-12-historic-structural-disasters/ [weburbanist.com] for some dramatic examples. From https://en.wikipedia.org/wiki/Fidenae#Stadium_disaster [wikipedia.org]

      In 27 AD, an apparently cheaply built wooden amphitheater constructed by an entrepreneur named Atilius collapsed in Fidenae, resulting in by far the worst stadium disaster in history. At least 20,000 were killed and many more injured out of the total audience of 50,000.

      It may take some time before we/humanity understand how to deal with this new stuff called software...

      • (Score: 2) by Mojibake Tengu on Saturday November 23 2019, @02:36PM

        by Mojibake Tengu (8598) on Saturday November 23 2019, @02:36PM (#923829) Journal

        Yes, this is exactly what I mean by preserving names. A history.
        The Roman Senate responded by requiring future stadiums to be inspected and certified.

        --
        The edge of 太玄 cannot be defined, for it is beyond every aspect of design
    • (Score: 0) by Anonymous Coward on Saturday November 23 2019, @02:39PM

      by Anonymous Coward on Saturday November 23 2019, @02:39PM (#923831)

      Current dogma of "keep up with software updates" is an insufficient strategy to mitigate, because when a backdoor is discovered and publicized, a corrupted author(s) just introduce(s) another one elsewhere, often very soon.

      Hanlon's Razor [wikipedia.org] almost always applies in such cases.

      As the old saw goes, "Two things are infinite, the universe and human stupidity."

      And that applies equally to those who attribute, without evidence or reasoned argument, what is in fact incompetence, laziness or stupidity to malice and/or conspiracy.

    • (Score: 2) by mth on Saturday November 23 2019, @04:21PM (1 child)

      by mth (2848) on Saturday November 23 2019, @04:21PM (#923856) Homepage

      I'd be very surprised if even one of these vulnerabilities was put there on purpose. I'm not saying it doesn't happen, but the vast majority is honest programming mistakes instead of sabotage.

      In my opinion we should stop writing huge complex systems in ways where small mistakes have big consequences. Stricter languages like Rust can help, as well as using sandboxing or capabilities to reduce the impact of an exploit.

      By the way, even if you are worried about deliberately inserted vulnerabilities, you are still better off upgrading your software: if you upgrade, you are vulnerable to one specific attacker, while if you don't upgrade after the vulnerability has been published you are vulnerable to every attacker out there.

      • (Score: 1, Informative) by Anonymous Coward on Saturday November 23 2019, @08:34PM

        by Anonymous Coward on Saturday November 23 2019, @08:34PM (#923950)

        ANY major project these days has a backlog of KNOWN UNFIXED BUGS numbered in HUNDREDS OF THOUSANDS and going back DECADES. If you think this does not affect security, you are naive. If you think using a hip language like Rust and DOING THE SAME THING WITH IT can help any, you are deluded.

  • (Score: 0) by Anonymous Coward on Saturday November 23 2019, @03:26PM (2 children)

    by Anonymous Coward on Saturday November 23 2019, @03:26PM (#923842)

    I have tightVNC on my server, does this get updated automatically by YUM?

    • (Score: 0) by Anonymous Coward on Saturday November 23 2019, @03:43PM

      by Anonymous Coward on Saturday November 23 2019, @03:43PM (#923847)
    • (Score: 0) by Anonymous Coward on Sunday November 24 2019, @06:35AM

      by Anonymous Coward on Sunday November 24 2019, @06:35AM (#924114)

      I'm going with "no" for three reasons. First is that yum doesn't update automatically by default, so if you have to ask then you've probably not enabled it or should, at least, assume you haven't. Second is this part of TFS, "All have now been patched, save for the bugs in TightVNC 1.x which were present in a no-longer supported version: you should be using version 2.x anyway." Third is that based on CentOS's terrible documentation, it does not appear that CentOS uses TightVNC or even package it.

  • (Score: 0) by Anonymous Coward on Saturday November 23 2019, @03:51PM (1 child)

    by Anonymous Coward on Saturday November 23 2019, @03:51PM (#923849)

    I use it in development to connect to a chroot. Piece of shit can't be configured to listen on localhost only, you have to separately firewall the public port. Also does 6 character passwords only for some alleged backward compatibility reason.

    I should just install from source and patch out the idiocy.

    • (Score: 4, Informative) by JoeMerchant on Saturday November 23 2019, @08:25PM

      by JoeMerchant (3937) on Saturday November 23 2019, @08:25PM (#923945)

      you have to separately firewall the public port.

      By design - ease of use vs security is a tradeoff. The most secure system is one with no access at all.

      I should just install from source and patch out the idiocy.

      Go for it, that's what open source is great for. As a practical matter, most people don't bother due to having to maintain both sides of the connection.

      The power of VNC is that it's cross platform, standard, and most implementations are pretty reliable.

      The weakness of VNC is that most people who implement a VNC server don't bother making their users jump through security hoops (myself included at the moment...) Good, solid security is available for VNC and any other client-server protocol via tunneling. Set yourselves up a secure tunnel (hundreds of flavors are available to choose from) and VNC securely all day and night.

      --
      My karma ran over your dogma.
(1)