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?
(Score: 3, Disagree) by Mojibake Tengu on Saturday November 23 2019, @01:45PM (5 children)
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
backdoorvulnerability authors. For better future.We can and should do that with open source, at least. With public repositories, we can do that retroactively.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 0) by Anonymous Coward on Saturday November 23 2019, @02:12PM (1 child)
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]
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
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.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 0) by Anonymous Coward on Saturday November 23 2019, @02:39PM
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)
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
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)
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
No. You need to wipe your '/' partition, reinstall, wipe it again, hop on one foot around your computer three times and then you'll be all set. [tecmint.com]
And you're welcome.
(Score: 0) by Anonymous Coward on Sunday November 24 2019, @06:35AM
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)
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 design - ease of use vs security is a tradeoff. The most secure system is one with no access at all.
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.
🌻🌻 [google.com]