CVE-2010-3856: High severity gnu c library vulnerability
ld.so in the GNU C Library (aka glibc or libc6) before 2.11.3, and 2.12.x before 2.12.2, does not properly restrict use of the LDAUDIT environment variable to reference dynamic shared objects (DSOs) as audit objects, which allows local users to gain privileges by leveraging an unsafe DSO located in a trusted library directory, as demonstrated by libpcprofile.so.
Other sources
Tavis Ormandy pointed out that glibc does not properly sanitize DSOs that are loaded using LDAUDIT facility. Tavis quoted:
In order to be preloaded during the execution of a privileged program, a library must be setuid and in the trusted library search path. This is a reasonable design, in order to be loaded a system administrator must brand a library as safe before it will be loaded across privilege boundaries.
This allows developers who design their programs to operate safely while running as setuid are able to do so. The same conditions do not apply to LDAUDIT, which will load an arbitrary DSOs, regardless of whether it has been designed to operate safely or not.
Tavis found out that by exploiting unsafely designed DSO constructors in trusted directories it is possible to achieve privilege escalation.
Acknowledgements:
Red Hat would like to thank Ben Hawkes and Tavis Ormandy for reporting this issue.
— Red Hat
Affected Software
Remediation
Patch Available
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2010-3856?
CVE-2010-3856 is considered a high severity vulnerability due to its potential for local privilege escalation.
How do I fix CVE-2010-3856?
To mitigate the risk from CVE-2010-3856, update the GNU C Library (glibc) to versions 2.11.3 or 2.12.2 and later.
Who is affected by CVE-2010-3856?
CVE-2010-3856 affects all versions of the GNU C Library (glibc) prior to 2.11.3 and certain versions of 2.12.x.
What can attackers do with CVE-2010-3856?
Attackers can exploit CVE-2010-3856 to execute arbitrary code with elevated privileges via the LD_AUDIT environment variable.
Is there a workaround for CVE-2010-3856?
A temporary workaround for CVE-2010-3856 is to restrict the use of the LD_AUDIT environment variable until the software can be updated.