I found a remote vulnerability (incorrect privilege assignment for client users of ftpd) in the ftpd in the Debian testing distribution. http://bugs.gentoo.org/show_bug.cgi?id=150292 tells me that Gentoo picked up Debian's changes, so I think this is a Gentoo vulnerability also, but I have not installed Gentoo. The Gentoo CVS page at http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/net-ftp/ftpd/files/ftpd-0.17-setguid.patch?rev=1.1 suggests that Gentoo has the same vulnerable code as the Debian testing distribution. Please let me know whether or not the Gentoo Linux Security Team can perform any necessary coordination with other Linux vendors. This is my best guess at the security problem in Gentoo: An incorrect patch in GLSA 200611-05 (use of "geteuid" where "getegid" was intended) introduces a new vulnerability into the net-ftp/ftpd in Gentoo. The new vulnerability is that all execution of /bin/ls by ftpd has gid 0 privileges. Clients of the ftpd (including anonymous ones) can list private directories in some filesystem configurations. I have confirmed the security problem in the Debian testing distribution. Here is the report I wrote for Debian testing. I have not sent this report anywhere except to Gentoo Bugzilla (I was unable to find any security contact address for the Debian testing distribution except for a publicly archived list. I'm aware of security@debian.org, but that's for Debian stable, and this vulnerability is apparently not in Debian stable.) (analysis of Debian testing vulnerability) I downloaded the testing ftpd from http://http.us.debian.org/debian/pool/main/l/linux-ftpd/ftpd_0.17-22_i386.deb as of 2325 GMT on November 15. The MD5 checksum was fd3d3c41e7fedce9899dfe73f4a5f032. This ftpd allows an unprivileged user account to execute /bin/ls with gid 0. For example: 220 debian.example.dom FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. ... ftp> cd /root 250 CWD command successful. ftp> dir ... drwxrwx--- 2 root root 4096 2006-11-15 12:23 private ... ftp> cd /root/private 550 /root/private: Permission denied. ftp> dir /root/private 227 Entering Passive Mode (10,0,0,215,146,240) 150 Opening ASCII mode data connection for '/bin/ls'. total 0 -rw-r--r-- 1 root root 0 2006-11-15 12:23 secret-filename.txt 226 Transfer complete. The gid 0 ownership of /root/private is what allows /bin/ls to succeed. For example, gid 1 ownership does not work: ftp> cd /root 250 CWD command successful. ftp> dir ... drwxrwx--- 2 root daemon 4096 2006-11-15 12:23 private ... ftp> dir /root/private 227 Entering Passive Mode (10,0,0,215,154,23) 150 Opening ASCII mode data connection for '/bin/ls'. /bin/ls: /root/private: Permission denied 226 Transfer complete. This security problem exists because of an incorrect patch introduced in handling the http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384454 bug report. Specifically, http://ftp.debian.org/debian/pool/main/l/linux-ftpd/linux-ftpd_0.17-22.diff.gz shows this change: --- linux-ftpd-0.17.orig/ftpd/popen.c +++ linux-ftpd-0.17/ftpd/popen.c @@ -169,8 +169,13 @@ * XXX: this doesn't seem right... and shouldn't * we initgroups, or at least setgroups(0,0)? */ - setgid(getegid()); - setuid(i); + +/* + * PSz 25 Aug 06 Must check the return status of these setgid/setuid calls, + * see http://www.bress.net/blog/archives/34-setuid-madness.html + */ + if ( setgid(geteuid()) != 0 ) _exit(1); + if ( setuid(i) != 0 ) _exit(1); In effect, this produces the code sequence: seteuid(0); if (setgid(geteuid()) != 0 ) _exit(1); if (setuid(i) != 0 ) _exit(1); execv(gargv[0], gargv); which gives the execv'd program (which is /bin/ls in this case) gid 0 privileges. I'd guess that the patch author intended to write if (setgid(getegid()) != 0 ) _exit(1); but instead wrote: if (setgid(geteuid()) != 0 ) _exit(1); thereby introducing a new security problem. The incorrect patch was apparently picked up by at least one other Linux vendor, Gentoo (see the very top of http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/net-ftp/ftpd/files/ftpd-0.17-setguid.patch?rev=1.1). Matt Power mhpower@mit.edu
Matt, thanks for letting us know, this is clearly an error. I'm surprised (and scared) that managed to get checked in without anyone noticing such a glaring mistake. I'll forward your report to the debian security folks, I'll CC you on the mail.
Chris can you correct the typo and attach an updated ebuild and patch to this bug ready to commit? Please do not commit anything yet.
Created attachment 102465 [details, diff] corrected patch Corrected patch attached.
adding debian maintainer
ok, this flew under the radar it seems and chriswhite is away atm ftpd is filed as maintainer-needed debian has this fixed for quite a while now btw <http://packages.qa.debian.org/l/linux-ftpd/news/20061125T181702Z.html> could someone here commit an updated ebuild or should we mask ftpd?
i'll just move it to base-system for now
renamed to netkit-ftpd, applied proposed patch here, cleaned up a bit, and committed 0.17-r5
thanks vapier arches, please test netkit-ftpd-0.17-r5, so people pick up the fixed patch
sparc stable.
net-ftp/netkit-ftpd-0.17-r5 USE="ssl" 1. emerges on x86 2. passes collision test 3. works Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.19.2 i686) ================================================================= System uname: 2.6.19.2 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz Gentoo Base System version 1.12.6 Last Sync: Fri, 26 Jan 2007 16:31:02 +0000 ccache version 2.4 [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FEATURES="autoconfig collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/" LINGUAS="en de en_GB de_CH" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi alsa apache2 asf berkdb bitmap-fonts cairo cdr cdrom cli cracklib crypt cups dbus divx dlloader dri dts dvd dvdr dvdread eds elibc_glibc emboss encode fam ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kdeenablefinal kernel_linux ldap libg++ linguas_de linguas_de_CH linguas_en linguas_en_GB mad mikmod mmx mono mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection rtsp ruby samba sdl session smp spell spl sse sse2 sse3 ssl svg tcpd test tetex theora threads truetype truetype-fonts type1-fonts udev unicode userland_GNU vcd video_cards_fbdev video_cards_i810 video_cards_vesa vorbis win32codecs wxwindows x264 xine xml xorg xprint xv xvid zlib" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
x86 stable
ppc stable
stable on alpha
Ping AMD64 This will need a GLSA update (200611-05)
amd64 stable
Update sent (GLSA UPDATE 200611-05), thanks to everybody.