CVE-2018-20020 (https://nvd.nist.gov/vuln/detail/CVE-2018-20020): LibVNC before commit 7b1ef0ffc4815cab9a96c7278394152bdc89dc4d contains heap out-of-bound write vulnerability inside structure in VNC client code that can result remote code execution CVE-2018-20021 (https://nvd.nist.gov/vuln/detail/CVE-2018-20021): LibVNC before commit c3115350eb8bb635d0fdb4dbbb0d0541f38ed19c contains a CWE-835: Infinite loop vulnerability in VNC client code. Vulnerability allows attacker to consume excessive amount of resources like CPU and RAM CVE-2018-20022 (https://nvd.nist.gov/vuln/detail/CVE-2018-20022): LibVNC before 2f5b2ad1c6c99b1ac6482c95844a84d66bb52838 contains multiple weaknesses CWE-665: Improper Initialization vulnerability in VNC client code that allows attacker to read stack memory and can be abuse for information disclosure. Combined with another vulnerability, it can be used to leak stack memory layout and in bypassing ASLR CVE-2018-20024 (https://nvd.nist.gov/vuln/detail/CVE-2018-20024): LibVNC before commit 4a21bbd097ef7c44bb000c3bd0907f96a10e4ce7 contains null pointer dereference in VNC client code that can result DoS.
CC'ing treecleaners.
Could you please explain the relation to ssvnc, since these advisories do not seem to mention it? Are we talking about a bundled library or...? Note to self: last release in 2011.
Got the answer on IRC.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec7ac0960b0777a94520c6049fbfce1c473fd957 commit ec7ac0960b0777a94520c6049fbfce1c473fd957 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-04-16 05:42:49 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-04-16 05:42:49 +0000 package.mask: Last rite net-misc/ssvnc Bug: https://bugs.gentoo.org/701820 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
(In reply to Michał Górny from comment #3) > Got the answer on IRC. May I inquire what was the answer ?
(In reply to pogosyan from comment #5) > (In reply to Michał Górny from comment #3) > > Got the answer on IRC. > > May I inquire what was the answer ? Ancient libvncclient (amongst others) bundled. Debian did fix (some?) of these: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945827 Somebody could in theory save this if they could gather together all of the patches but the last upstream release was 2011. I kind of doubt there is no better alternative in 2020 to ssvnc, but I may be proven wrong. VNC as an ecosystem uses a lot of bundled libs which need to be kept up to date. Some of TigerVNC's code is included here which seems pretty out of date too.
Is there any possibility to keep this in repo? Do you know any alternative VNC client allowing to make connection over SSH?
+1 to previous comment. If you are going to remove ssvnc, then what is the alternative for VNC over SSH? Since the reported CVEs are on the bundled libvncclient, then it would seem that for this to be exploited, then an attacker would need to compromise the SSH layer, which would render these vulnerabilities moot. Assuming there is no better alternative being actively supported, I would suggest fixing the reported CVEs on the bundled libvncclient using Debian's patches from Jessie LTS and keeping the ssvnc ebuild in tree.
(In reply to David Turner from comment #8) > +1 to previous comment. If you are going to remove ssvnc, then what is the > alternative for VNC over SSH? > > Since the reported CVEs are on the bundled libvncclient, then it would seem > that for this to be exploited, then an attacker would need to compromise the > SSH layer, which would render these vulnerabilities moot. > > Assuming there is no better alternative being actively supported, I would > suggest fixing the reported CVEs on the bundled libvncclient using Debian's > patches from Jessie LTS and keeping the ssvnc ebuild in tree. 1) Connecting to a VNC server doesn't mean you trust it (a lot - such that it won't try do anything malicious). It could have been replaced by a malicious instance even if you trust the remote machine. 2) A simple alternative is ssh -L ... in the command line. I think some other VNC clients do support either SSL or SSH (TigerVNC or TurboVNC do from my recollection, but can't be sure). 3) You are welcome to submit a PR with the Debian patches. I'm not generally out to kill packages - I will usually patch maintainer-needed things but in this case I just didn't have the energy to do it. I would have to test it and so on.
I agree with points 1 & 2, though ssvnc does have some advantages over basic SSH forwarding. It would be nice to get the same code as a simpler wrapper script round any SSH and VNC client ... though that is someone else's project :) I have retrieved the Debian patches and reviewed them. They are pretty simple and self contained changes. I am going to attach them to this bug along with an ebuild patch. I have tested these and they work fine. Do I need to do anything else to submit these to the Portage tree as a Pull Request? i.e. is this via Github or another service?
Created attachment 634760 [details] CVE-2018-20020 Patch
Created attachment 634762 [details, diff] CVE-2018-20021 Patch
Created attachment 634764 [details, diff] CVE-2018-20022 Patch
Created attachment 634766 [details, diff] CVE-2018-20024 Patch
Created attachment 634768 [details, diff] Patch to SSVNC-1.0.29 EBuild to Add CVE-2018-2002{0,1,2,4} Patches
(In reply to David Turner from comment #10) > I agree with points 1 & 2, though ssvnc does have some advantages over basic > SSH forwarding. It would be nice to get the same code as a simpler wrapper > script round any SSH and VNC client ... though that is someone else's > project :) > > I have retrieved the Debian patches and reviewed them. They are pretty > simple and self contained changes. I am going to attach them to this bug > along with an ebuild patch. I have tested these and they work fine. > > Do I need to do anything else to submit these to the Portage tree as a Pull > Request? i.e. is this via Github or another service? So, this package is maintainer-needed. Either you need to get a Gentoo developer to take it up, or you / someone needs to become a proxy-maintainer. This means committing to fixing any bugs which come up and so on - and keeping an eye on any further patches which might come up. If you're ok to do that, you should make a PR on github (you can do it here but github is preferred) and ping someone in #gentoo-proxy-maint if you don't hear something ~week afterwards.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c221e57b59ee49a37fb30025dffb3cfaa8bf1ee5 commit c221e57b59ee49a37fb30025dffb3cfaa8bf1ee5 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-05-23 09:24:24 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-05-23 09:29:23 +0000 net-misc/ssvnc: Remove last-rited pkg Closes: https://bugs.gentoo.org/701820 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/ssvnc/Manifest | 1 - net-misc/ssvnc/files/Makefile.libvncauth | 7 - net-misc/ssvnc/files/Makefile.vncviewer | 8 - net-misc/ssvnc/files/ssvnc-1.0.29-build.patch | 44 ----- net-misc/ssvnc/files/ssvnc-1.0.29-openssl1.1.patch | 199 --------------------- net-misc/ssvnc/metadata.xml | 8 - net-misc/ssvnc/ssvnc-1.0.29-r2.ebuild | 64 ------- profiles/package.mask | 6 - 8 files changed, 337 deletions(-)
Reopening because one of the vulnerabilities allows RCE, so we need a removal GLSA for this.
This issue was resolved and addressed in GLSA 202006-06 at https://security.gentoo.org/glsa/202006-06 by GLSA coordinator Aaron Bauman (b-man).
