Bugzilla Bug 142661

As noted in bug #136916, there's trouble with libvncserver. As solar pointed
out, net-misc/ltsp comes with an own version as the grep shows:

net-misc/ltsp/ltsp-4.1-r1.ebuild:
http://www.ltsp.org/ltsp-4.1/ltsp-libvncserver-1.0-0-i386.tgz
net-misc/ltsp/ltsp-4.1.1.ebuild:
http://www.ltsp.org/ltsp-4.1/ltsp-libvncserver-1.1-0-i386.tgz

Could you check whether the reported problem is in there, too?

Thanks!

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 an attachment (id=105280) [details]
LTSP no VNC support quick patch

Created an attachment (id=105281) [details]
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.