CVE-2024-41667
Assigned by [email protected]
OpenAM is an open access management solution. In versions 15.0.3 and prior, the `getCustomLoginUrlTemplate` method in RealmOAuth2ProviderSettings.java is vulnerable to template injection due to its usage of user input. Although the developer intended to implement a custom URL for handling login to override the default OpenAM login, they did not restrict the `CustomLoginUrlTemplate`, allowing it to be set freely. Commit fcb8432aa77d5b2e147624fe954cb150c568e0b8 introduces `TemplateClassResolver.SAFER_RESOLVER` to disable the resolution of commonly exploited classes in FreeMarker template injection. As of time of publication, this fix is expected to be part of version 15.0.4.
Weaknesses (CWE)
CWE-94 — Improper Control of Generation of Code ('Code Injection')
PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.
CVSS
8.8
Base Score: 8.8/10 HIGH
Exploitability: 2.8/10
Impact: 5.9/10
Access Vector
- Availability: HIGH
- Confidentiality: HIGH
- Integrity: HIGH
Impact
Attack Patterns (CAPEC)
CAPEC-242 — Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
Typical severity: High
Prerequisites: The target software does not validate user-controlled input such that the execution of a process may be altered by sending code in through legitimate data channels, using no other mechanism.
Solutions: Utilize strict type, character, and encoding enforcement Ensure all input content that is delivered to client is sanitized against an acceptable content specification. Perform input validation for all content. Enforce regular patching of software.
CAPEC-35 — Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
Typical severity: Very High
Prerequisites: The attacker must have the ability to modify non-executable files consumed by the target software.
Solutions: Design: Enforce principle of least privilege Design: Run server interfaces with a non-root account and/or utilize chroot jails or other configuration techniques to constrain privileges even if attacker gains some limited access to commands. Implementation: Perform testing such as pen-testing and vulnerability scanning to identify directories, programs, and interfaces that grant direct access to executables. Implementation: Implement host integrity monitoring to detect any unwanted altering of configuration files. Implementation: Ensure that files that are not required to execute, such as configuration files, are not over-privileged, i.e. not allowed to execute.
CAPEC-77 — Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
Typical severity: Very High
Prerequisites: A variable consumed by the application server is exposed to the client. A variable consumed by the application server can be overwritten by the user. The application server trusts user supplied data to compute business logic. The application server does not perform proper input validation.
Solutions: If the register_globals option is enabled, PHP will create global variables for each GET, POST, and cookie variable included in the HTTP request. This means that a malicious user may be able to set variables unexpectedly. For instance make sure that the server setting for PHP does not expose global variables. A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Separate the presentation layer and the business logic layer. Variables at the business logic layer should not be exposed at the presentation layer. This is to prevent computation of business logic from user controlled input data. Use encapsulation when declaring your variables. This is to lower the exposure of your variables. Assume all input is malicious. Create an allowlist that defines all valid input to the software system based on the requirements specifications. Input that does not match against the allowlist should be rejected by the program.
References
https://github.com/OpenIdentityPlatform/OpenAM/commit/fcb8432aa77d5b2e147624fe954cb150c568e0b8
https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-7726-43hg-m23v
https://github.com/OpenIdentityPlatform/OpenAM/commit/fcb8432aa77d5b2e147624fe954cb150c568e0b8
https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-7726-43hg-m23v
