FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

LinkBack Thread Tools
Old 06-06-2011, 04:36 AM
Ben Hutchings
Default Bug#629373: Remote DoS with vsftpd on Linux 2.6.32

Package: vsftpd
Version: 2.3.2-3
Tags: security
Severity: important
X-Debbugs-Cc: debian-kernel@lists.debian.org

The bug is described by Serge Hallyn below, and in Ubuntu bug #720095

In short, I agree with Serge that the network namespace feature in the
kernel is useful and should be retained in squeeze, given that only
privileged users can (directly) use it. vsftpd must not create a
network namespace per connection without a kernel version check.


-------- Forwarded Message --------
From: Serge Hallyn <serge.hallyn@canonical.com>
To: kernel-team@lists.ubuntu.com, ubuntu-server@lists.ubuntu.com
Date: Wed, 1 Jun 2011 13:57:38 -0500


vsftpd spawns a network namespace in response to each client connection.
Lucid kernel is slow to release network namespaces, which results, in
bug 720095, in an easy remote DOS. The maverick kernel has a fix for
this, but it is hard to cherrypick.

The bug was resolved by compiling the lucid kernel without
CONFIG_NET_NS. I'm emailing to ask that we reconsider that solution.

Turning off CONFIG_NET_NS prevents libvirt from creating all containers
(lxc:///), and prevents lxc from creating most useful containers,
resulting in bug 790863. There is the workaround of installing the
backported kernel, but I don't believe that will satiate users who
really want LTS stability. For those users, we are effectively telling
them that they cannot use containers until 12/04.

What I don't believe has been discussed is that CLONE_NEWNET requires
privilege. The vsftpd bug was bad because anyone could trigger it with
a set of remote connections. But that is easily fixed by patching
vsftpd to not use CLONE_NEWNET. As Stefan noted in irc, there is the
threat that other services use CLONE_NEWNET. Though I've grepped some
of my local sources for samba, dhclient, postfix, apache, mysql, squid
etc, and have found no others using CLONE_NEWNET so far. That doesn't
mean there aren't any, but I argue that the risk is far outweighed by
not supporting containers in lucid.

Thanks for your time


kernel-team mailing list

Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Thread Tools

All times are GMT. The time now is 04:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org