From $URL : A time-of-check time-of-use (TOCTOU) race condition flaw was found in the way ProFTPD, flexible, stable and highly-configurable FTP server, handled MKD/XMKD FTP commands when the UserOwner directive was involved. A local attacker could use this flaw to possibly escalate their privileges via symbolic-link attacks on directories, created by ProFTPD prior UserOwner ownership was applied. Upstream bug report: [1] http://bugs.proftpd.org/show_bug.cgi?id=3841 Relevant upstream patch: [2] http://bugs.proftpd.org/show_bug.cgi?id=3841#c8 References: [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697524
CVE-2012-6095 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-6095): ProFTPD before 1.3.5rc1, when using the UserOwner directive, allows local users to modify the ownership of arbitrary files via a race condition and a symlink attack on the (1) MKD or (2) XMKD commands.
The tree got fixed ebuild 'net-ftp/proftpd-1.3.4c' (fixed upstream).
(In reply to comment #2) > The tree got fixed ebuild 'net-ftp/proftpd-1.3.4c' (fixed upstream). Thanks, Sergei. Should we stabilize that one or the -r1 ?
(In reply to comment #3) > (In reply to comment #2) > > The tree got fixed ebuild 'net-ftp/proftpd-1.3.4c' (fixed upstream). > > Thanks, Sergei. Should we stabilize that one or the -r1 ? It's safer to stabilize '=net-ftp/proftpd-1.3.4c'. -r1 differs only by new modules. I'd ike to have them in ~arch for a while.
(In reply to comment #2) > The tree got fixed ebuild 'net-ftp/proftpd-1.3.4c' (fixed upstream). Arches, please test and mark stable. Target KEYWORDS: "alpha amd64 ~arm hppa ~ia64 ~mips ppc ppc64 sparc x86"
We need to stabilize >=dev-libs/libmemcached-0.41 first, because =net-ftp/proftpd-1.3.4c[memcache] depends on it. There is a stablereq for =dev-libs/libmemcached-0.50 here -> bug #443518
Stable for HPPA.
amd64 stable
x86 stable
ppc stable
ppc64 stable
alpha stable
sparc stable
+ 09 Jul 2013; Michael Weber <xmw@gentoo.org> package.mask: + Masked <net-ftp/proftpd-1.3.4c for security bug 450746, CVE-2012-6095 +
please stable on arm as well
(In reply to Rick Farina (Zero_Chaos) from comment #16) > please stable on arm as well Negative. Security stable requests are not meant to first stabilize a package on a new arch. File a separate request.
GLSA vote: yes
This issue was resolved and addressed in GLSA 201309-15 at http://security.gentoo.org/glsa/glsa-201309-15.xml by GLSA coordinator Sean Amoss (ackle).