From ${URL} : Stephane Chazelas discovered that directory traversal issue in locale handling in glibc. glibc accepts relative paths with ".." components in the LC_* and LANG variables. Together with typical OpenSSH configurations (with suitable AcceptEnv settings in sshd_config), this could conceivably be used to bypass ForceCommand restrictions (or restricted shells), assuming the attacker has sufficient level of access to a file system location on the host to create crafted locale definitions there. Bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=17137 Git commits: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=d183645616b Related alloca hardening (technically not covered by the CVE assignment) https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4e8f95a0df7 Actual fix https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=58536726692 Documentation updates (To backport the new test in a reliable fashion, you need to tweak the Makefile to set the LOCPATH environment variable.) @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
CVE-2014-0475 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0475): Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.
From Upstream: "08 Septtember 2014 The GNU C Library version 2.20 is now available" https://sourceware.org/ml/libc-alpha/2014-09/msg00088.html Maintainer(s): after the bump please let us know when the ebuild is ready for stabilization.
fix is also in glibc-2.20-r2 now
err, ignore that ... fix is in all 2.20 releases obviously
(In reply to SpanKY from comment #4) > err, ignore that ... fix is in all 2.20 releases obviously Indeed, thanks for backporting the fixes for the related (now marked as blocked by this bug) Please call for stabilization when you consider that the package has gotten appropriate testing and is ready for it.
This issue was resolved and addressed in GLSA 201602-02 at https://security.gentoo.org/glsa/201602-02 by GLSA coordinator Tobias Heinlein (keytoaster).