Summary: | net-misc/ltsp: Check for vulnerabilty in ltsp's bundled libvncserver | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Wolf Giesen (RETIRED) <frilled> |
Component: | Auditing | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | fauli, warwick |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.gentoo.org/show_bug.cgi?id=136916, ltsp bundled version | ||
Whiteboard: | C1 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
LTSP no VNC support quick patch
LTSP no VNC support quick patch |
Description
Wolf Giesen (RETIRED)
2006-08-03 08:05:43 UTC
This one slipped my mind ... the dependencies indicate this to be a major PITA (bundled libvncserver, openssl) without neither maintainer nor herd. Suggestions? As there is no maintainer, no reverse dependencies we should just punt this package. I will step up to do so, if you (security) are okay with it. From my personal perspective I'd like to encourage you in doing so! Is hard masked, see announcement in -dev I have a quick diff to temporarily disable vnc in LTSP at all. Created attachment 105280 [details, diff]
LTSP no VNC support quick patch
Created attachment 105281 [details, diff]
LTSP no VNC support quick patch
Thusa (our company), under my direction will take over this ebuild. Please let me know who I need to speak with. (In reply to comment #8) > Thusa (our company), under my direction will take over this ebuild. Please let > me know who I need to speak with. > http://www.gentoo.org/proj/en/devrel/ or recruiters@g.org or IRC, freenode.net, #gentoo-devrel Or you could use your local overlay. (In reply to comment #8) > Thusa (our company), under my direction will take over this ebuild. Please let > me know who I need to speak with. I am here, so we can use this bug to communicate. I have submitted a report and fix to the LTSP tean now await their response. It is copied below: First off, I need to verify whether there is infact an exploit in LTSP 4.1/2's libvncserver packages. The exploit concerned is: CVE-2006-2450 From what I can see, LTSP-4.2 uses LibVNCServer-0.7pre.tar.gz and and per Gentoo bug #136916, the rest of Gentoo upgraded to LibVNCServer-0.8.2.tar.gz. The Changelog for the 0.8.2 release contains the following entry: 2006-07-12 Karl Runge <runge@karlrunge.com> * libvncserver: release for CVE-2006-2450 fix. I assume it would be prudent that LibVNCServer be upgraded to 0.8.2 for the next maintenance release of LTSP 4.2, but, from what I can see in the package.def file in the LBE, all this package is used for is x11vnc and nothing else: INSTALL = cp contrib/x11vnc ${LTSP_ROOT}/usr/X11R6/bin/x11vnc It also appears that LibVNCServer-0.8.2 does not build an x11vnc binary any longer. If this is the case, we should infact remove libvncserver from LTSP and use x11vnc-0.8.3 instead: 1. Rename libvncserver in /usr/local/lbe/ltsp-src/package_list to x11vnc 2. mv /usr/local/lbe/ltsp-src/libvncserver /usr/local/lbe/ltsp-src/x11vnc 3. Edit the package.def file as per example included below 4. Compile breaks on linux fb support, so I have added the --without-fbdev option the configure tcs lbe # cat ltsp-src/x11vnc/package.def # # package.def file for building a package in the the LTSP build environment # # Copyright (c) 2003 by James A. McQuillan (McQuillan Systems, LLC) # # This software is licensed under the Gnu General Public License. # The full text of which can be found at http://www.LTSP.org/license.txt # VERSION = 1.1 RELEASE = 1 PKG1COMPONENT = ltsp_core PKG1NAME = ltsp-libvncserver DEPENDS = ltsp-ltsptree, ltsp-glibc, ltsp-xorg PKG1 = x11vnc-0.8.3.tar.gz MD5SUM1 = 8f94bb7180d1a0c303a125f4ae31ca2a SOURCE1 = ${TARBALL_SOURCE}/${PKG1} UNPACK1 = gunzip < ${TARBALL} | tar xf - BUILDDIR = x11vnc-0.8.3 CONFIGURE = export CFLAGS="-march=i386" && \ ./configure --without-fbdev BUILD = make -j ${CPUS} CFLAGS="-march=i386 -I .." INSTALL = cp x11vnc/x11vnc ${LTSP_ROOT}/usr/X11R6/bin/x11vnc CLEAN = rm -rf ${BUILDDIR} ${SOURCEDIR} Note: The Gentoo bug as regard LTSP being hard masked in the portage tree is 142661: http://bugs.gentoo.org/show_bug.cgi?id=142661 ok, update here. the ltsp crowd are not going to release an update for ltsp-4.2 incorporating the proposed fix. their efforts are going towards ltsp 5. additionally, they are not averse to the ebuild being dropped: <jammcq> budgee: we didn't put LTSP into gentoo, we we weren't really concerned about it being removed. For 4.2, we'd rather have people install it the "official" way with ltspadmin Additionall, LTSP reckon vnc is not used in LTSP 4.2: <jammcq> we included it, cuz we *thought* we'd have remote assistance easily available <jammcq> that never happened Thus, I propose we just accept Vanya's patch which removes libvncserver (the x11vnc binary) and focus efforts on LTSP5 on Gentoo. (In reply to comment #12) > Thus, I propose we just accept Vanya's patch which removes libvncserver (the > x11vnc binary) and focus efforts on LTSP5 on Gentoo. Fine, I will apply that as 4.2-r1 and remove -r0. Security, are you then satisfied, so I can unmask ltsp again? 4.1 is stable for x86, but is not affected, while 4.2 is totally ~arch. Good job Warwick, thanks > > Fine, I will apply that as 4.2-r1 and remove -r0. Security, are you then > satisfied, Security is always happy when the vulnerability disappears :) > so I can unmask ltsp again? Sure Securty, i would like your opinion on a GLSA for this bug. We must know if the affected component (auth.c) could actually been used. Thanks Surely if the package is removed in entirety, then there is no need for the GLSA? LibVNCServer's auth.c was used to by the x11vnc binary, which is the only part of LibVNCServer distributed with LTSP. By removing this package from the ebuild, we are removing LibVNCServer and it's faulty auth.c If you are referring in general to the fact that no GLSA has been released against CVE-2006-2450, then ignore this comment. -r1 committed, please test, then I will remove -r0 and clean it from package.mask Security, please stop voting here. As I just found out, version 4.1-r1 of ltsp is vulnerable, too. It has no vnc USE flag, but vnc is always installed. So after unmasking, 4.2-r1 needs to be stabled on x86! I second that. With the move to LTSP 5, 4.1 may as well be back in the dark ages. (In reply to comment #16) > Surely if the package is removed in entirety, then there is no need for the > GLSA? why not? some users are using a vulnerable ebuild, a GLSA is aimed to warn them. Even if in the new ebuild the risk is avoided. Indeed, they might continue to use the old ebuild. > > If you are referring in general to the fact that no GLSA has been released > against CVE-2006-2450, then ignore this comment. i don't understand: see 200608-05 and 200608-12 about this issue. > Hi arches, please could you test ltsp-4.2-r1 : this package has to be unmasked and tested for stable marking. amd64 had no previous stable version, removing. x86 marked stable. Has been unmasked. Security. What is the status of this bug? It is stabled, unmasked and so on. Will you vote for a glsa or just close it? (In reply to comment #23) > Security. What is the status of this bug? It is stabled, unmasked and so on. > Will you vote for a glsa or just close it? > Security is out of order and i hardly manage to catch up the late, sorry. There will be a GLSA. (In reply to comment #24) > (In reply to comment #23) > > Security. What is the status of this bug? It is stabled, unmasked and so on. > > Will you vote for a glsa or just close it? > Security is out of order and i hardly manage to catch up the late, sorry. > There will be a GLSA. What is the state here? A GLSA draft is waiting in the queue. I guess it will be send shortly. GLSA200703-19. Thanks everyone, sorry for the delay in closing. |