From ${URL} : CVE-2014-6051 Integer overflow in MallocFrameBuffer() on client side. A malicious VNC server could advertise a very large screen size (by RFB protocol, width and height are 16-bit integers), resulting in an integer overflow during malloc() on client-side. Heap corruption, and possibly remote code execution on client-side could ensue. CVE-2014-6052 Lack of malloc() return value checking on client side. malloc() return value was not checked on client-side during framebuffer setup. A malicious VNC server that advertises a large enough screen size to make malloc() fail could basically map the framebuffer at address 0, and write anything-anywhere in client process memory using selective FramebufferUpdate messages. This could certainly turn into remote code execution on client-side. CVE-2014-6053 Server crash on a very large ClientCutText message. A malicious client could advertise a very large ClientCutText message size (by RFB protocol, size is encoded on a 32-bit integer). malloc() is likely to fail in that case; as malloc() return value is not checked, this will most likely result in a server crash. Note: this issue also affects RealVNC as per CVE-2010-5304. http://www.iss.net/security_center/reference/vuln/VNC_Client_Cut_Text_DoS.htm http://packetstormsecurity.com/files/89160/RealVNC-VNC-Server-Free-Edition-4.1.3-Denial-Of-Service.html CVE-2014-6054 Server crash when scaling factor is set to zero. A malicious client could set the scaling factor to 0, which will result in a server crash (division by zero). CVE-2014-6055 Multiple stack overflows in File Transfer feature. 1/ The non-standard file transfer messages (UltraVNC feature) will blindly strcpy() client-provided file and directory names into a stack-based buffer of size MAX_PATH, resulting in multiple stack-based buffer overflows on server-side. 2/ Client-supplied FileTime attribute is copied into a stack-based buffer of size 64 during rfbFileTransferOffer message parsing, resulting in a stack-based buffer overflow on server-side. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
CVE-2014-6055 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6055): Multiple stack-based buffer overflows in the File Transfer feature in rfbserver.c in LibVNCServer 0.9.9 and earlier allow remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a (1) long file or (2) directory name or the (3) FileTime attribute in a rfbFileTransferOffer message. CVE-2014-6054 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6054): The rfbProcessClientNormalMessage function in libvncserver/rfbserver.c in LibVNCServer 0.9.9 and earlier allows remote attackers to cause a denial of service (divide-by-zero error and server crash) via a zero value in the scaling factor in a (1) PalmVNCSetScaleFactor or (2) SetScale message. CVE-2014-6053 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6053): The rfbProcessClientNormalMessage function in libvncserver/rfbserver.c in LibVNCServer 0.9.9 and earlier does not properly handle attempts to send a large amount of ClientCutText data, which allows remote attackers to cause a denial of service (memory consumption or daemon crash) via a crafted message that is processed by using a single unchecked malloc. CVE-2014-6052 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6052): The HandleRFBServerMessage function in libvncclient/rfbproto.c in LibVNCServer 0.9.9 and earlier does not check certain malloc return values, which allows remote VNC servers to cause a denial of service (application crash) or possibly execute arbitrary code by specifying a large screen size in a (1) FramebufferUpdate, (2) ResizeFrameBuffer, or (3) PalmVNCReSizeFrameBuffer message. CVE-2014-6051 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-6051): Integer overflow in the MallocFrameBuffer function in vncviewer.c in LibVNCServer 0.9.9 and earlier allows remote VNC servers to cause a denial of service (crash) and possibly execute arbitrary code via an advertisement for a large screen size, which triggers a heap-based buffer overflow.
Created attachment 400624 [details] libvncserver-0.9.10.ebuild
please review and test the attached ebuild then commit. also, please set me as the maintainer for libvncserver.
Created attachment 400650 [details] build log (In reply to Alex Xu (Hello71) from comment #3) > please review and test the attached ebuild then commit. also, please set me > as the maintainer for libvncserver. # emerge libvncserver -1 worked fine # USE="gcrypt gnutls ipv6" emerge libvncserver -1 USE="threads vaapi" emerge libvncserver -1 drew error. It's close. archtester libvncserver # grep "Error 1" /mnt/gen2/TmpDir/portage/net-libs/libvncserver-0.9.10/temp/build.log make[2]: *** [rfbproto.lo] Error 1 make[1]: *** [all-recursive] Error 1 I guess this is to do with kde-base/krfb but I haven't looked hard. I am out of mt normal realm here. Also this came up. * GNU info directory index is up-to-date. !!! existing preserved libs: >>> package: media-libs/glew-1.12.0 * - /usr/lib64/libGLEW.so.1.9 * - /usr/lib64/libGLEW.so.1.9.0 * used by /usr/lib64/misc/xscreensaver/biof (x11-misc/rss-glx-0.9.1) * used by /usr/lib64/misc/xscreensaver/busyspheres (x11-misc/rss-glx-0.9.1) * used by /usr/lib64/misc/xscreensaver/colorfire (x11-misc/rss-glx-0.9.1) * used by 20 other files >>> package: media-gfx/imagemagick-6.9.0.3 * - /usr/lib64/libMagickWand-6.Q16.so.1 * - /usr/lib64/libMagickWand-6.Q16.so.1.0.0 * used by /usr/lib64/misc/xscreensaver/drempels (x11-misc/rss-glx-0.9.1) * used by /usr/lib64/misc/xscreensaver/matrixview (x11-misc/rss-glx-0.9.1) * - /usr/lib64/libMagickCore-6.Q16.so.1 * - /usr/lib64/libMagickCore-6.Q16.so.1.0.0 * used by /usr/lib64/misc/xscreensaver/drempels (x11-misc/rss-glx-0.9.1) * used by /usr/lib64/misc/xscreensaver/matrixview (x11-misc/rss-glx-0.9.1) >>> package: media-gfx/exiv2-0.24-r1 * - /usr/lib64/libexiv2.so.13 * - /usr/lib64/libexiv2.so.13.0.0 * used by /usr/lib64/kde4/kfilemetadata_exiv2extractor.so (kde-base/kfilemetadata-4.14.3) * used by /usr/lib64/libgwenviewlib.so.4.14.6 (kde-base/gwenview-4.14.3) * used by /usr/lib64/strigi/strigiea_jpeg.so (app-misc/strigi-0.7.8-r1) Use emerge @preserved-rebuild to rebuild packages using these libraries which can normally be cured by setting QA vars just before, in this case, src_prepare(). The ebuild passes repoman fine otherwise. Doing well though.
sorry cancel comment re QA vars, was skim reading and read the output highlighted in * as QA warnings.
Created attachment 400686 [details] libvncserver-0.9.10.ebuild v2 (In reply to Ian Delaney from comment #4) > Created attachment 400650 [details] > build log > > (In reply to Alex Xu (Hello71) from comment #3) > > please review and test the attached ebuild then commit. also, please set me > > as the maintainer for libvncserver. > > # emerge libvncserver -1 worked fine > # USE="gcrypt gnutls ipv6" emerge libvncserver -1 > USE="threads vaapi" emerge libvncserver -1 > > drew error. It's close. > > archtester libvncserver # grep "Error 1" > /mnt/gen2/TmpDir/portage/net-libs/libvncserver-0.9.10/temp/build.log > make[2]: *** [rfbproto.lo] Error 1 > make[1]: *** [all-recursive] Error 1 > > I guess this is to do with kde-base/krfb but I haven't looked hard. I am out > of mt normal realm here. > > Also this came up. > * GNU info directory index is up-to-date. > > !!! existing preserved libs: > >>> package: media-libs/glew-1.12.0 > * - /usr/lib64/libGLEW.so.1.9 > * - /usr/lib64/libGLEW.so.1.9.0 > * used by /usr/lib64/misc/xscreensaver/biof (x11-misc/rss-glx-0.9.1) > * used by /usr/lib64/misc/xscreensaver/busyspheres > (x11-misc/rss-glx-0.9.1) > * used by /usr/lib64/misc/xscreensaver/colorfire > (x11-misc/rss-glx-0.9.1) > * used by 20 other files > >>> package: media-gfx/imagemagick-6.9.0.3 > * - /usr/lib64/libMagickWand-6.Q16.so.1 > * - /usr/lib64/libMagickWand-6.Q16.so.1.0.0 > * used by /usr/lib64/misc/xscreensaver/drempels > (x11-misc/rss-glx-0.9.1) > * used by /usr/lib64/misc/xscreensaver/matrixview > (x11-misc/rss-glx-0.9.1) > * - /usr/lib64/libMagickCore-6.Q16.so.1 > * - /usr/lib64/libMagickCore-6.Q16.so.1.0.0 > * used by /usr/lib64/misc/xscreensaver/drempels > (x11-misc/rss-glx-0.9.1) > * used by /usr/lib64/misc/xscreensaver/matrixview > (x11-misc/rss-glx-0.9.1) > >>> package: media-gfx/exiv2-0.24-r1 > * - /usr/lib64/libexiv2.so.13 > * - /usr/lib64/libexiv2.so.13.0.0 > * used by /usr/lib64/kde4/kfilemetadata_exiv2extractor.so > (kde-base/kfilemetadata-4.14.3) > * used by /usr/lib64/libgwenviewlib.so.4.14.6 > (kde-base/gwenview-4.14.3) > * used by /usr/lib64/strigi/strigiea_jpeg.so (app-misc/strigi-0.7.8-r1) > Use emerge @preserved-rebuild to rebuild packages using these libraries > > which can normally be cured by setting QA vars just before, in this case, > src_prepare(). The ebuild passes repoman fine otherwise. > > Doing well though. Oh yeah, I remember that error. It's fixed in the next release which should be... any time now...
Created attachment 400688 [details] libvncserver-0.9.10.ebuild v3 DEPEND should be virtual/jpeg:0 now. get some dependency.badindev warnings, but those are because overlays don't inherit use.mask (or something).
I can safely say I am missing the new patch libvncserver-0.9.10-libva-1.0.patch or I have missed finding it here
Created attachment 400760 [details] libvncserver-0.9.10-libva-1.0.patch
/net-libs/libvncserver $ USE="gcrypt gnutls ssl threads vaapi" ebuild libvncserver-0.9.10.ebuild clean install * Removing unnecessary /usr/lib64/libvncserver.la (no static archive) * Removing unnecessary /usr/lib64/libvncclient.la (no static archive) >>> Completed installing libvncserver-0.9.10 into /mnt/gen2/TmpDir/portage/net-libs/libvncserver-0.9.10/image/ passes repoman checks *libvncserver-0.9.10 (07 Apr 2015) 07 Apr 2015; Ian Delaney <idella4@gentoo.org> +files/libvncserver-0.9.10-libva-1.0.patch, +libvncserver-0.9.10.ebuild, metadata.xml: bump; add required patch sourced from upstream, setting herd to proxy- maintainers and proxy maintainer to Alex Xu, all wrt sec bug #523590 Arch teams please make stable bumped net-libs/libvncserver-0.9.10 Target keywords: ~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 ppc64 was missed in 0.9.9-r3 but was done previously. I see no reason why it need not be done here.
(In reply to Ian Delaney from comment #10) > Target keywords: ~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 Probably not.
Stable for HPPA.
amd64 stable
x86 stable
alpha stable
ia64 stable
ppc64 stable
Created attachment 401746 [details] libvncserver-0.9.10-r1.ebuild forgot to add vaapi to econf. please commit as -r1 and then re-add amd64, x86 herds for re-stabilization. libva is only keyworded there, so other archs should stable 0.9.10.
ppc stable
(In reply to Alex Xu (Hello71) from comment #18) > Created attachment 401746 [details] > libvncserver-0.9.10-r1.ebuild Any special reason why you have dropped all KEYWORDS other than ~amd64 and ~x86 (and their prefix equivalents) here?
libvncserver-0.9.10-r1 committed to CVS, on behalf of Alex Xu (Hello71). Straight to stable on those architectures which have the vaapi flag in use.mask and where -r0 was marked stable already. Readding amd64 and x86 to CC. Arch teams, please stabilise: net-libs/libvncserver-0.9.10-r1 Target keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
There is now a libvncserver-0.9.10-r2.ebuild subsequent to Bug 548012.
There is now a libvncserver-0.9.10-r3.ebuild, the missed config entries required another revbump. Cancel libvncserver-0.9.10-r2.ebuild
sparc stable
arm stable, all arches done.
drop <=libvncserver-0.9.9-r3
03 Jun 2015; Ian Delaney <idella4@gentoo.org> -libvncserver-0.9.8.2-r2.ebuild, -libvncserver-0.9.9-r1.ebuild, -libvncserver-0.9.9-r2.ebuild, -libvncserver-0.9.9-r3.ebuild, -libvncserver-0.9.9.ebuild, libvncserver-0.9.10-r3.ebuild: forwarding stable of amd64 and arm, rm old re prompt from maintainer wrt bug 523590
Hello71, for the future when changing whiteboard please set it to "glsa?", so that security team knows to take action. glsa is for when we file a glsa request, which was never done. New GLSA Request filed.
This issue was resolved and addressed in GLSA 201507-07 at https://security.gentoo.org/glsa/201507-07 by GLSA coordinator Mikle Kolyada (Zlogene).
