The CVS pserver bug - a timeline [LWN.net]

Quick response to security incidents is considered one of the strong points of the free software community. It is also seen as a vital component of a site's defenses against attacks. With that in mind, it is worth taking a look at how the recent CVS vulnerability played out:

May 2	Stefan Esser discovers a vulnerability in CVS, up to versions 1.11.15 and 1.12.7. A buffer overflow in the "entry" line parsing code would allow an attacker to execute arbitrary code on the system when the "pserver" access technique is being used. Mr. Esser informs the CVS developers, and is told almost immediately that a fix has been prepared.
May 3	Various high-profile CVS sites are informed of the problem and its fix.
May 12	A new patch is prepared after SourceForge discovers a problem with the previous versions.
May 19	The "coordinated public disclosure" happens, just in time to screw up the LWN publication deadline. Updates are released by Debian, Fedora, Mandrake, Red Hat, Slackware, and SUSE.
May 20	Gentoo releases its updated cvs package.
May 27	CERT gets around to sending out an advisory on the vulnerability.

A few quick conclusions can be drawn from this sequence of events:

The coordinated disclosure mechanism had some glitches in its early days, but it seems to be working well now. The problem was kept quiet for a couple of weeks, after which most major distributors were able to issue patches almost simultaneously.
One may well wonder, again, what the relevance of CERT is; it took just over a week to get an advisory out after the public disclosure. By then, anybody who was paying attention had already closed the hole.
Some distributions do not yet have updates out. These include Conectiva, Whitebox, and Trustix. (Update: Trustix lacks an update because it does not ship CVS, our mistake). Red Hat Linux users are also exposed; the Fedora Legacy project has not yet issued a cvs update.

The last item is somewhat troubling. Given the nature of this vulnerability and the availability of information, no serious distributor should have failed to have an update ready on the disclosure day. One can thus conclude that some distributors are more serious than others. In particular, it is worth noting that the projects which rework Red Hat distributions and updates (Whitebox, CentOS, Fedora Legacy) have failed to react to this vulnerability in a timely way. It may well be that, if you lack the structure necessary to create a distribution in the first place, you will be hard pressed to keep that distribution secure.

(Log in to post comments)

The CVS pserver bug - a timeline

Posted Jun 3, 2004 1:47 UTC (Thu) by sweikart (guest, #4276) [Link]

>In particular, it is worth noting that the projects which rework Red Hat
>distributions and updates (Whitebox, CentOS, Fedora Legacy) have failed to
>react to this vulnerability in a timely way. It may well be that, if you lack
>the structure necessary to create a distribution in the first place, you will
>be hard pressed to keep that distribution secure.

Progeny Transition Services sent out email announcing their TSSA-2004:4810-01 patches for RHL releases at noon on May 20.

Did X/OS or Tao Linux do any better then Whitebox and CentOS for RHEL?

The CVS pserver bug - a timeline

Posted Jun 3, 2004 16:43 UTC (Thu) by X-Nc (guest, #1661) [Link]

It isn't surprising to me that WBEL and Tao would be delayed as both of these are one man shows. That's not to excuse them for being slow in releasing the fixes. But I thought that cAos, being a group/organization (like some others "Cough-Debian-Cough") would have had something out faster. Maybe I'm mistaken about how CentOS-3 is developed & managed.

-- If I actuallycould spell I'd have spelled it right in the first place.

The CVS pserver bug - a timeline

Posted Jun 3, 2004 20:35 UTC (Thu) by tmattox (subscriber, #4169) [Link]

CentOS 3.1 had a security fix out on May 19th, which seems pretty fast to me.

See CentOS's mailing list archive here:

http:// caosity.org/pipermail/centos-devel/2004-May/000214.html

The CVS pserver bug - a timeline

Posted Jun 3, 2004 17:52 UTC (Thu) by mongre26 (guest, #4224) [Link]

Personally I am not so concerned that WBEL were not lightning fast all things considered. They were still responsive in a timely fashion in my opinion.

First of all the software services that come with a WBEL install are the least of my worries. I have dozens of services on the systems that I manage that are addons to a base install that may have holes a mile wide for all I know (research software). For those packages I have to assume updates will be slow, if not available at all. As a result I need to take steps beyond what comes out of the box to mitigate the risk these packages expose my systems to.

On the issue of pserver specifically. Who actually runs pserver without chrooting it anyway? pserver is pretty much regarded in the same light as tftp, a security whole waiting to be exploited buffer overflow or not. If you are serious about remote cvs access you should be using ssh, preferably with RSA or Kerberos authentication. They people that should be concerned are those using pserver in the first place, especially if it was not chrooted as the ample documentation on the internet suggests.

BEL gives me incredible value for an unbeatable price and if they are behind a day or two I am not loosing sleep over it.

chrooting cvs pserver

Posted Jun 5, 2004 23:38 UTC (Sat) by sweikart (guest, #4276) [Link]

>Who actually runs pserver without chrooting it anyway?

Truly. Here's the contents of my /etc/xinetd.d/cvspserver, including special arguments used to debug files missing from the chroot jail. You'll probably need to merge the lines I split with the trailing \

# default: on
# description: CVS pserver, uses CVS's own password file

service cvspserver
{
        disable         = no
        flags           = REUSE
        only_from       = YOUR-IP-ADDRESS-GOES-HERE 127.0.0.1
        socket_type     = stream
        wait            = no
        user            = root
        nice            = -1
# method to discover what files are missing from chroot jail
#       server          = /usr/bin/strace
#       server_args     = -o/tmp/cvs.strace /usr/sbin/chroot \
          /chroot/cvs /usr/bin/cvs -f --allow-root=/var/local/cvs pserver
        server          = /usr/sbin/chroot
        server_args     = /chroot/cvs /usr/bin/cvs \
          -f --allow-root=/var/local/cvs pserver
        cps             = 20 3
        log_on_failure  += USERID HOST
}

The CVS pserver bug - a timeline

Posted Jun 3, 2004 20:08 UTC (Thu) by skvidal (subscriber, #3094) [Link]

and as another comment:

fedora legacy opened this report:
https://bugzilla.fedora.us/show_bug.cgi?id=1620

then put packages into testing-updates. There was a problem in adep for one package but that's been corrected.

They should be pushed sometime this weekend.

Again, you should do some research before you accuse people and groups of 'failing to react'.

-sv

CentOS 3.1's cvs security update was available on May 19th

Posted Jun 3, 2004 23:15 UTC (Thu) by tmattox (subscriber, #4169) [Link]

An update for CentOS 3.1 was announced on both the community and developer mailing lists on May 19th as the update was becoming available on the global mirror system. With yum update running daily from cron, which is easy to configure with just

chkconfig yum on; service yum start

CentOS 3.1 users could have been safe within 24-48 hours of the public announcement. (Thanks to RedHat for supplying a source code patch quickly so that this could happen.) See:

http://caosity.org/pipermail/centos/2004-May/000178.html
http://caosity.org/pipermail/centos-devel/2004-May/000214.html

I enjoy reading LWN, but please check your facts for these kinds of things.