Common Vulnerabilities and Exposures assigned an identifier CVE-2010-3192 to the following vulnerability: Certain run-time memory protection mechanisms in the GNU C Library (aka glibc or libc6) print argv[0] and backtrace information, which might allow context-dependent attackers to obtain sensitive information from process memory by executing an incorrect program, as demonstrated by a setuid program that contains a stack-based buffer overflow error, related to the __fortify_fail function in debug/fortify_fail.c, and the __stack_chk_fail (aka stack protection) and __chk_fail (aka FORTIFY_SOURCE) implementations. References: [1] http://seclists.org/fulldisclosure/2010/Apr/399 [2] http://www.openwall.com/lists/oss-security/2010/08/25/8 [3] http://www.openwall.com/lists/oss-security/2010/08/31/6 [4] http://www.openwall.com/lists/oss-security/2010/08/31/7 [5] http://www.openwall.com/lists/oss-security/2010/09/02/2 [6] http://www.openwall.com/lists/oss-security/2010/09/02/3 [7] http://www.openwall.com/lists/oss-security/2010/09/02/4 [8] http://www.openwall.com/lists/oss-security/2010/09/02/5
Upstream bug closed WONTFIX: http://sourceware.org/bugzilla/show_bug.cgi?id=12189
Gentoo has long been replacing the stack chk handler with its own implementation that goes out of its way to use syscalls directly and not C lib funcs. it also does not call backtrace() which is mostly what the CVE complains about. as for argv[0], bite me ... `ps` can usually give you the same thing. so that part of the report is INVALID for Gentoo's shipping glibc. fortify failures do still print out a backtrace, but those checks occur before the actual functions are executed, so the backtrace output shouldnt be operating on corrupted memory. on the off chance it does, consider this a WONTFIX -- the output is useful to people, and upstream isnt changing it.
