CVE Vulnerabilities

CVE-2024-23331

Improper Handling of Case Sensitivity

Published: Jan 19, 2024 | Modified: Jan 29, 2024
CVSS 3.x
7.5
HIGH
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu

Vite is a frontend tooling framework for javascript. The Vite dev server option server.fs.deny can be bypassed on case-insensitive file systems using case-augmented versions of filenames. Notably this affects servers hosted on Windows. This bypass is similar to CVE-2023-34092 – with surface area reduced to hosts having case-insensitive filesystems. Since picomatch defaults to case-sensitive glob matching, but the file server doesnt discriminate; a blacklist bypass is possible. By requesting raw filesystem paths using augmented casing, the matcher derived from config.server.fs.deny fails to block access to sensitive files. This issue has been addressed in vite@5.0.12, vite@4.5.2, vite@3.2.8, and vite@2.9.17. Users are advised to upgrade. Users unable to upgrade should restrict access to dev servers.

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
Vite Vitejs 2.7.0 (including) 2.9.17 (excluding)
Vite Vitejs 3.0.0 (including) 3.2.8 (excluding)
Vite Vitejs 4.0.0 (including) 4.5.2 (excluding)
Vite Vitejs 5.0.0 (including) 5.0.12 (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