Insecure Library Loading
Play Labs on this vulnerability with SecureFlag!
Description
Insecure Library Loading refers to software defects where an application doesn’t properly manage how it creates and uses new processes or libraries. In particular, it allows those processes or libraries to be invoked from untrusted or insufficiently validated sources. This often occurs when a program loads libraries or executes commands in an environment that is under the influence of an attacker, allowing malicious code, libraries, or system commands to be run under the application’s authority.
These vulnerabilities stem from:
- Neglecting to validate or sanitize library paths, environment variables, or process creation parameters.
- Loading libraries from attacker-controlled locations, such as writable directories or network shares.
- Failing to enforce strict privilege controls, allowing malicious libraries to execute with elevated permissions.
Impact
If an Insecure Library Loading vulnerability exists, attackers can trick the application into executing or loading malicious code. This allows them to run arbitrary code with the privileges of the compromised application or service.
Scenarios
Untrusted Library Loading: An application dynamically loads a shared library based on a user-supplied path (e.g., LoadLibrary(user_input)). An attacker can point the application to a malicious library on the file system or network share, leading to remote code execution once the library is loaded.
Unvalidated Environment Setup: Before spawning a child process, an application modifies system or environment variables that determine the location of executables or libraries. If these variables come from untrusted input, an attacker can manipulate them to ensure a malicious binary or library is invoked instead of a legitimate one.
Remote Command Execution via Process Creation: Similar to OS Command Injection, an application might spawn a process with parameters derived from unsanitized user input. Rather than loading a specific library file, an attacker can specify an alternate command or file to run, hijacking the newly spawned process.
Prevention
When loading libraries or executing processes, specify absolute, trusted paths. Store libraries and executables in directories with strict access controls that prevent attacker tampering.
Whenever possible, limit the use of external process execution and dynamic loading. If functionality can be achieved within the application’s codebase (e.g., using built-in APIs), this significantly reduces exposure.
Validate or sanitize user inputs that are used to determine library names, command parameters, or environment variables. Reject or sanitize data that includes path traversal symbols or unexpected file extensions.
Enforce code signing to ensure that only libraries or executables signed by trusted authorities can be loaded. This technique helps prevent attackers from substituting malicious files.
Run processes at the lowest necessary privilege level. Even if an attacker manages to load a malicious library or spawn a new process, the impact is contained by strict privilege boundaries.
Testing
Inspect and monitor which libraries are being loaded by the application at runtime. Confirm that no untrusted or unexpected libraries appear in the load chain.
Verify that environment variables, file paths, and other external parameters cannot be manipulated by untrusted sources to influence process creation or library loading.
- OWASP ASVS: 5.3.8