CVE Vulnerabilities

CVE-2020-5301

Improper Handling of Case Sensitivity

Published: Apr 21, 2020 | Modified: Sep 14, 2021
CVSS 3.x
3.1
LOW
Source:
NVD
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.x
3.5 LOW
AV:N/AC:M/Au:S/C:P/I:N/A:N
RedHat/V2
RedHat/V3
Ubuntu

SimpleSAMLphp versions before 1.18.6 contain an information disclosure vulnerability. The module controller in SimpleSAMLModule that processes requests for pages hosted by modules, has code to identify paths ending with .php and process those as PHP code. If no other suitable way of handling the given path exists it presents the file to the browser. The check to identify paths ending with .php does not account for uppercase letters. If someone requests a path ending with e.g. .PHP and the server is serving the code from a case-insensitive file system, such as on Windows, the processing of the PHP code does not occur, and the source code is instead presented to the browser. An attacker may use this issue to gain access to the source code in third-party modules that is meant to be private, or even sensitive. However, the attack surface is considered small, as the attack will only work when SimpleSAMLphp serves such content from a file system that is not case-sensitive, such as on Windows. This issue is fixed in version 1.18.6.

Weakness

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

Affected Software

Name Vendor Start Version End Version
Simplesamlphp Simplesamlphp * 1.18.6 (excluding)

Extended Description

Improperly handled case sensitive data can lead to several possible consequences, including:

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

References