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 LD_AUDIT env…
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 LD_AUDIT 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.
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
https://cwe.mitre.org/data/definitions/264.html →Open in CWE collection →The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
https://cwe.mitre.org/data/definitions/426.html →Open in CWE collection →This pattern of attack sees an adversary load a malicious resource into a program's standard path so that when a known command is executed then the system instead executes the malicious component. The adversary can either modify the search path a program uses, like a PATH variable or classpath, or they can manipulate resources on the path to point to their malicious components. J2EE applications and other component based applications that are built from multiple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker.
https://capec.mitre.org/data/definitions/38.html →Open in CAPEC collection →| Product | Vendor | Status |
|---|---|---|
| eglibc | Tracked | |
| glibc | Tracked | |
| glibc | Tracked | |
| glibc | Tracked | |
| glibc | Tracked | |
| glibc | * | Tracked |