It is suspected that this package is vulnerable to a security vulnerability in LZO. As such we ask maintainers with packages suspected to be vulnerable to verify if the package is (or have been) affected. Please see the information contained in the tracker bug 515246. "An integer overflow may occur when processing any variant of a "literal run" in the lzo1x_decompress_safe function. Each of these three locations is subject to an integer overflow when processing zero bytes.", additional information about the upstream vulnerability is available at http://seclists.org/oss-sec/2014/q2/665 Reproducible: Didn't try
if necessary, we can patch this locally by just copying in LZO from upstream; chances of regression are slim afaik.
upstream bug was resolved, but some funky stuff seems to have happened with the releases and the project was moved somewhere along the way and the build system was rewritten or something like that.
I'm calling this a C3 because: 1) it only applies where the attacker can control the VNC connection (meaning already authenticated) 2) generally the configuration is that x11vnc runs with user privileges 3) typically an authenticated user can already perform actions at the privilege of the x11vnc user, which means they can already execute code or kill x11vnc. 4) there is no evidence of a RCE being feasible with just LZO, let alone how it is used in libvncserver. feel free to correct if any of the above assumptions are incorrect.
oops.
Alex look at the Vulnerability treatment policy. We just assign the whiteboard based on the vulnerability and not the method of attack. Or the frequency of use. The B = Pulled in by default. Since net-libs/libvncserver is pulled in by: kde-base/krdc and since that is pulled in by default by kde-base/kdenetwork-meta without the user knowing it is a B.
Created attachment 401824 [details] x11vnc-0.9.13_p20150111.ebuild new x11vnc required because all x11vnc releases bundle libvncserver.
Created attachment 401826 [details] x11vnc-0.9.13_p20150111.ebuild v2 please review and commit.
(In reply to Alex Xu (Hello71) from comment #7) > Created attachment 401826 [details] > x11vnc-0.9.13_p20150111.ebuild v2 > > please review and commit. ebuild manages ~/cvsPortage/gentoo-x86/x11-misc/x11vnc $ ebuild x11vnc-0.9.13_p20150111.ebuild clean install >>> Completed installing x11vnc-0.9.13_p20150111 into /mnt/gen2/TmpDir/portage/x11-misc/x11vnc-0.9.13_p20150111/image/ strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version usr/bin/x11vnc ecompressdir: bzip2 -9 /usr/share/doc ecompressdir: bzip2 -9 /usr/share/man repoman full yields RepoMan scours the neighborhood... KEYWORDS.dropped 1 x11-misc/x11vnc/x11vnc-0.9.13_p20150111.ebuild: arm64 dependency.missingslot 3 x11-misc/x11vnc/x11vnc-0.9.13-r1.ebuild: RDEPEND: 'dev-libs/openssl' matches more than one slot, please specify an explicit slot and/or use the := or :* slot operator x11-misc/x11vnc/x11vnc-0.9.13-r1.ebuild: RDEPEND: 'dev-lang/tk' matches more than one slot, please specify an explicit slot and/or use the := or :* slot operator x11-misc/x11vnc/x11vnc-0.9.13_p20150111.ebuild: RDEPEND: 'dev-libs/openssl' matches more than one slot, please specify an explicit slot and/or use the := or :* slot operator 1. Simply re-add arm64 to KEYWORDS 2. I believe the use of := would be fine for dev-libs/openssl, dev-lang/tk
(hit return unintentionally) & dev-libs/openssl. 3. KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~sparc-solaris ~x64-solaris ~x86-solaris" could also re reduced after adding arm64 however this would be an option at your discretion. Some of these are defunct or excess to arches that likely really need them.
Created attachment 401866 [details] x11vnc-0.9.13_p20150111.ebuild v3
ah; dev-lang/tk came from x11vnc-0.9.13-r1.ebuild so I ought not have included that. *x11vnc-0.9.13_p20150111 (24 Apr 2015) 24 Apr 2015; Ian Delaney <idella4@gentoo.org> +x11vnc-0.9.13_p20150111.ebuild: bump wrt bug #515268, runtests fine
(In reply to Ian Delaney from comment #9) > (hit return unintentionally) > > & dev-libs/openssl. > 3. KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh > ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux > ~sparc-solaris ~x64-solaris ~x86-solaris" > could also re reduced after adding arm64 however this would be an option at > your discretion. Some of these are defunct or excess to arches that likely > really need them. actually, the keywords don't even make sense because libvncserver is a mandatory dep now. you can drop ~arm64, ~x86-interix, *-solaris. dlan, if you want it on arm64, then test libvncserver with x11vnc and keyword both together. I don't know when the interix/solaris keywords were added, so I can't tell whoever did it.
x11-misc/x11vnc-0.9.13_p20150111: target keywords: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86 note: arm64 not required but dlan you can add if you want. libvncserver stabilization continues in bug 523590.
Stable for PPC64.
Stable for HPPA.
amd64 stable
ppc stable
x86 stable
arm stable
glsa in bug 523590
bleh, mixed this up with the other one.
sparc stable
alpha stable
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
Author: Ian Delaney <idella4@gentoo.org> Date: Sat Sep 26 23:21:06 2015 +0800 x11-misc/x11vnc: rm old, clean up for sec bug #515268
Thank you for cleaning up x11-misc/x11vnc. Can we please clean up =net-libs/libvncserver-0.9.10 GLSA Vote: No
(In reply to Yury German from comment #26) > Thank you for cleaning up x11-misc/x11vnc. > Can we please clean up > =net-libs/libvncserver-0.9.10 > > GLSA Vote: No yes, anyone should feel free to remove <=net-libs/libvncserver-0.9.10-r1. (not -r3 or -r4).
commit 1716aea7db079ad590ddccc831bbaa2d3f0c9f15 Author: Ian Delaney <idella4@gentoo.org> Date: Sun Sep 27 10:46:58 2015 +0800 net-libs/libvncserver: rm old, clean up for sec bug #515268
Maintainer(s), Thank you for you for cleanup.
(In reply to Yury German from comment #26) > Thank you for cleaning up x11-misc/x11vnc. > Can we please clean up > =net-libs/libvncserver-0.9.10 > > GLSA Vote: No GLSA Vote: No