Tavis Ormandy pointed out that glibc does not properly sanitize DSOs that are loaded using LD_AUDIT 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 LD_AUDIT, 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.
Reference: http://seclists.org/fulldisclosure/2010/Oct/344
Created glibc tracking bugs for this issue Affects: fedora-all [bug 645875]
Andreas Patch: http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html Thanks, Roberto Yokota
This issue did not affect the versions of glibc package as shipped with Red Hat Enterprise Linux 3 and 4 as these do not implement Auditing API for the dynamic linker.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0793 https://rhn.redhat.com/errata/RHSA-2010-0793.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2010:0872 https://rhn.redhat.com/errata/RHSA-2010-0872.html