LWN.net Weekly Edition for July 21, 2005 [LWN.net]

Debconf5: Structural Evolution

Debconf5, the sixth annual Debian Conference, recently descended upon the Helsinki University of Technology (HUT) in Espoo, Finland. LWN reporter Rebecca Sobol was privileged to attend this year's event.

Hundreds of Debian developers, maintainers, translators, users and fans joined together for an overflowing week's worth of talks, BOFs, hacking and partying. Debian GNU/Linux is the largest distribution project in many ways; lots of developers (around 200 Debian Developers plus scores of package maintainers, documentation authors and translators), support for more architectures, lots of packages (nearly 15,000 binary packages are available), more derived distributions using it as a base, and soon even a choice between Linux and Hurd kernels. The Debian community is massive and scattered around the globe.

During the year these people keep in touch through a variety of mailing lists and IRC channels, but the annual Debconf provides people with a chance to meet face to face to talk about their favorite operating system. Each year Debconf meets in a different part of the world to make it more accessible to some portion of its global community. This year's conference in Finland brought out over ninety Finns, followed by a full gross of people from Germany, the United Kingdom, the United States, Sweden, Spain and Norway. It was also accessible to a handful of people from the Russian Federation and other parts of Eastern Europe. A few traveled greater distances to come from South America, New Zealand and Fiji. All told, there were people from over thirty countries at this year's event.

Debian is large, and it is all volunteer. A few people have found or created jobs for themselves where they can be paid to work on Debian, at least part of the time, but they are in the minority. The organization is guided by a social contract and maintains a strong commitment to software freedom.

Bdale Garbee, long time Debian developer and former Debian Project Leader gave a talk on Debian's Structural Evolution, subtitled Musings on Debian, Today and Tomorrow. He has serious concerns that Debian has grown too large for its infrastructure. For example, each year Debian developers elect a Project Leader. For nine weeks each year a few prominent Debian developers cease working as a team to compete for a job that has grown too complex for a single person. Only Debian developers are allowed to vote, leaving hundreds, or more likely thousands of Debian volunteers and users with no say whatsoever.

Some of Debian's infrastructure is ably provided by Software in the Public Interest (SPI). However too few Debian developers are involved in SPI, which oversees many other projects. Also it not in SPI's mandate to provide technical guidance, that is the role of the Technical Committee. Bdale finds the committee, as currently defined, is not particularly satisfying. The committee could use a periodic review and refresh, which is currently not happening.

The current DPL, Branden Robinson started Project SCUD as an attempt to address some of these issues while working within the constraints of the Debian constitution. However Bdale (a member of SCUD) finds that the relationship between the DPL and the project is not clear. The team is self-selected and does not include a representative sampling of Debian project participants.

Perhaps it is time to replace the DPL and Technical Committee with an elected leadership board. Candidates would be motivated to campaign on their teamwork skills and more people would be willing to be involved in Debian's leadership. Perhaps a way could be found to allow the greater Debian community a voice in this process. Perhaps this would make Debian even stronger.

Comments (10 posted)

Delays in security updates

July 20, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

There are a number of reasons that users choose Linux, but security is one of the most often-cited reasons. While Linux distributions certainly see their fair share of security issues, updates are usually issued in a timely fashion.

However, there are times when the process gets bogged down. Security updates for Debian, for example, were not going out in a timely fashion for some time. As reported in Branden Robinson's Debian Project Leader Report for July, security updates were interrupted for some time. This has also been reported in the mainstream press, though members of the Debian team take issue with the actual reporting.

Looking at the security advisories for 2005, one thing that is clear is that no security updates were issued through most of June. There are no updates from June 4 through June 29. Updates resumed on June 30, and there have been a steady stream of updates since then. We e-mailed Martin Schulze about the Debian security delays, and he confirmed the time period.

That is quite a delay for some of the updates. For example, the sudo vulnerability, for example, was addressed in Debian on July 1 for Woody and Sarge. The Fedora Core team released an update for this vulnerability for Fedora Core 3 and Fedora Core 4 on June 21, and Ubuntu released an update on June 21st for Hoary (5.04) and Warty (4.10). Updates for Gaim's recent vulnerabilities were issued on June 16 for FC3 and FC4, and June 10 and June 15 by the Ubuntu team, respectively -- but not for Debian until July 5.

In an e-mail, Schulze said that he didn't know all of the details of the problems that delayed updates, but explained way the process is supposed to work:

When a new release happens the old release, formerly known as "stable", becomes "oldstable" and "testing" becomes "stable."

This change needs to be done on the ftp-master, on the security host and on the wanna-build database (the database behind the buildd network).

In addition to that, on all buildd hosts that are supposed to build packages for "oldstable" as well (not all buildds do), the old "stable" build chroot needs to be renamed to "oldstable" and "oldstable" needs to be enabled in the configuration.

Additionally, on all buildd hosts the "stable" build chroot needs to be updated to the current "stable," or the old "testing" chroot renamed. These are used by the security builds as well.

All this should be done synchronously, but wasn't. On July 7th I wrote in my logbook that the buildd network seems to be finally fixed. Actually it was fixed two days before that article. Before that, one part or another was missing or not fixed totally.

In the Project Leader Report, Robinson points out that there was a failure in infrastructure and communication:

I suspect, given what I know from conversation with some of the principals close to the infrastructure involved in getting our stable security updates out, that that's what we're dealing with. There have been technical failures and communication failures, with the former greatly exacerbated by the latter.

I have asked Andreas Barth to look into this situation and establish as clear a factual record as he can. Using this report, we should be able to attack the areas of weakness. One thing I'd like to see is better documentation of the internal workings of the security update process, perhaps in the Debian Developers' Reference. With a broader understanding of security workflow, I'm hopeful that people will be less likely to draw erroneous inferences about what the causes of problems are, and more likely to make offers of assistance that prove fruitful.

Robinson has also proposed making the security team DPL delegates, and points out that now would be a good time to add new members to the security team roster. Whether that has happened or not, however, remains up in the air. Schulze said that adding new members would be "discussed inside the security team." Robinson has not replied to e-mails asking about the security delays.

Schulze also said that the backlog of security updates that built up through June should be cleared out by now.

Around the same time, the Fedora Legacy project's security updates also seem to have been bottled up. The Fedora Legacy project has a gap for updates between June 5 and July 9, for all Red Hat and Fedora distributions supported by the Fedora Legacy project, Red Hat 7.3 and 9.0, and Fedora Core 1 and Fedora Core 2.

Some of the updates that were released in July by Fedora Legacy were rather tardy indeed. For example the GNU Mailman advisory (CAN-2005-0202), was fixed by other distributions back in February. The PHP advisory on July 10 from Fedora Legacy was addressed back in April by Gentoo, Mandriva and others. (Debian's fix for this bug came out in May.) This post on the Fedora Legacy mailing list from Jesse Keating acknowledges that the legacy project has longer lead times on security updates.

It would seem that Debian's infrastructure problems have been solved, at least for now. However, the gap in updates is somewhat alarming. As a rule, Debian has often been one of the first distributions to issue security updates and advisories, and has developed a well-deserved reputation for being quick to respond to security issues. We hope that the delay in updates while the project was transitioning from Woody to Sarge is a one-time issue, and that the transition from Sarge to Etch, whenever that happens, will happen more smoothly.

The importance of speedy security releases can't be emphasized enough. Aside from the obvious PR problems when a distribution is behind in updates, Linux users need to be able to depend on updates as soon as they can be made available so that they are not subject to exploits any longer than is absolutely necessary.

Comments (2 posted)

Page editor: Rebecca Sobol

Security

Brief items

Debconf5: Securing the Testing Distribution

This part of our Debconf5 coverage was inspired by a talk titled Securing the Testing Distribution given by Joey Hess. Debconf5 sign

Debian has several branches, including two currently supported stable branches, Woody and Sarge and the unstable branch, also known as sid. Though usually fairly stable, sid is in constant flux and provides a faster paced target for those who like run the latest and greatest software. The testing branch, on the other hand, provides a look at the next stable version still in development, in this case etch. Testing was first used when woody was in development. Once Woody was released as Debian 3.0 testing became synonymous with sarge. So now that Sarge has been released as Debian 3.1, testing has become etch which will someday to be the next stable version.

The supported stable version(s) (support for Woody will end before we will see an etch release) have a security team providing security updates. Often security fixes are backported to the stable packages. Packages in sid are usually upgraded to a new version of the package in which the problem has been fixed. Up to now there has been no mechanism to provide security updates for testing.

Some of the security issues in stable will have already been fixed in testing's newer packages, but for the most part security fixes have lagged behind stable and unstable. Packages fixed in unstable can automatically migrate to testing, if certain criteria are met, but that comes with a built-in delay. Unrelated release critical bugs in unstable packages could block the security updates from reaching testing. Ironically, those very users most interested in the shape of the next stable version are also those likely to be put off by the lack of security updates.

Those days have come to end. Now there is a security team for testing, with five to six team members and twice that on the mailing list. Some team members are Debian Developers (DDs), but that's not required. The team now proactively looks for holes, checking Debian testing packages against CVE entrys, bugs in the Bug Tracking System (BTS), and watching other security lists.

DDs and package maintainers were asked to document all security issues, including the CVE number in open bug reports. Change log entries and closed bugs should include a CVE number and indicate when security issues are fixed. Tracking and fixing security bugs in etch will make it far more appealing to potential testers, and may even help Debian achieve a more predictable release cycle.

Comments (2 posted)

New vulnerabilities

affix: two remote vulnerabilities

Package(s):

affix

CVE #(s):

CAN-2005-2250 CAN-2005-2277

Created:

July 19, 2005

Updated:

September 2, 2005

Description:

A buffer overflow in the Bluetooth FTP client (BTFTP) in Nokia Affix 2.1.2 and 3.2.0 allows remote attackers to execute arbitrary code via a long filename in an OBEX file share. Also remote attackers may execute arbitrary commands via shell metacharacters in the filename argument of a PUT command.

Alerts:

Debian

DSA-762-1

2005-07-19

LWN.net Weekly Edition for July 21, 2005

affix: two remote vulnerabilities

bugzilla: information disclosure

ekg: multiple vulnerabilities

heartbeat: insecure temporary files

kdelibs: kate backup file permission leak

mediawiki: JavaScript code injection

mozilla-firefox: multiple vulnerabilities

mysql: low-impact security fix

pam_ldap: plain text authentication leak

phppgadmin: directory traversal vulnerability

thunderbird mozilla firefox: multiple vulnerabilities

CUPS: multiple vulnerabilities

cvs: multiple vulnerabilities

a2ps: input validation error

acroread: arbitrary code execution

bzip2: race condition and infinite loop

cacti: SQL injection and PHP file inclusion

centericq: temporary file vulnerability

cpio - file permissions error

cpio: directory traversal

cURL: buffer overflow

cvs: multiple vulnerabilities

cyrus-imapd: buffer overflows

dbus: information disclosure

dhcp: format string vulnerability

dhcpcd: denial of service

Dnsmasq: poisoning and DoS

emacs21: format string vulnerability in "movemail"

enscript: arbitrary code execution

ettercap: format string vulnerability

evolution: message crash vulnerability

Foomatic: Arbitrary command execution in foomatic-rip

FUSE: information disclosure

gdb: multiple vulnerabilities

gtk-pixbuf, gtk2: denial of service

gedit: format string vulnerability

gettext: Insecure temporary file handling

gftp: missing input sanitizing

ghostscript: symlink vulnerabilities

glibc: tempfile vulnerability in catchsegv script

gnupg: information leak

grip: buffer overflow

groff: insecure temporary directory

gxine: format string vulnerability

gzip: race condition and directory traversal

Heimdal: buffer overflow vulnerabilities

ht: arbitrary code execution

htdig: cross site scripting

ImageMagick: xwd coder denial of service

imap: buffer overflow in c-client

imlib2: buffer overflows

infozip: privilege escalation, directory-traversal

junkbuster: heap corruption and settings modification

kdelibs: unsanitzied input

kernel: ELF loader core dump vulnerability

kernel: multiple vulnerabilities

kernel: multiple vulnerabilities

kimgio input validation errors

krb5: double-free flaw

leafnode: fetchnews vulnerabilities

libconvert-uulib-perl: arbitrary code execution

libdbi-perl: insecure temporary file

libgd2: buffer overflows in PNG handling

libnet-ssleay-perl: weakened cryptographic operations

libTIFF: buffer overflow

libxml2 - arbitrary code execution

libxml2: multiple buffer overflows

libXpm: new buffer overflows

lvm10: creates insecure temporary directory

mailman: path traversal

mc: buffer overflow

mod_python: remote access vulnerability

Mozilla Firefox, Mozilla Suite: multiple vulnerabilities

mozilla firefox: javascript vulnerabilities

MySQL: input validation and temporary file vulnerabilities

ncpfs: multiple vulnerabilities

Net-SNMP: fixproc insecure temporary file creation

nfs-utils: arbitrary code execution

openssh: directory traversal