CVE-2014-9512 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9512): rsync 3.1.1 allows remote attackers to write to arbitrary files via a symlink attack on a file in the synchronization path. @maintainers: is rsync 3.1.1 ready for stabilization?
Arches please test and mark stable =net-misc/rsync-3.1.1 with target KEYWORDS: alpha amd64 arm ~arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh sparc x86 ~ppc-aix ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris
Stable for HPPA.
amd64 stable
x86 stable
I stabilized but I did not understand at all the bug. > rsync 3.1.1 allows remote attackers to write to arbitrary files via a > symlink attack on a file in the synchronization path. The description says that 3.1.1 is vulnerable, then why we are stabilizing 3.1.1?
(In reply to Agostino Sarubbo from comment #5) > I stabilized but I did not understand at all the bug. > > > rsync 3.1.1 allows remote attackers to write to arbitrary files via a > > symlink attack on a file in the synchronization path. > > The description says that 3.1.1 is vulnerable, then why we are stabilizing > 3.1.1? You are of course correct. Are we aware of any fix for this issue?
(In reply to Kristian Fiskerstrand from comment #6) > You are of course correct. Are we aware of any fix for this issue? The nvd description points to https://bugzilla.samba.org/show_bug.cgi?id=10977 which says there is a fix...but I imagine is more a workaround.
arm stable
Since we hare half way through stabilization of net-misc/rsync-3.1.1 Do we want to complete the stabilization?
This bug report is weird. Stable for PPC64.
sparc stable
alpha stable
ppc stable
Debian Patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778333 Upstream included this in 3.1.2 which is stable in the tree: https://git.samba.org/?p=rsync.git;a=commit;h=962f8b90045ab331fc04c9e65f80f1a53e68243b Added to existing GLSA.
This issue was resolved and addressed in GLSA 201605-04 at https://security.gentoo.org/glsa/201605-04 by GLSA coordinator Yury German (BlueKnight).