GHSA-jjgj-cx3q-pw4w OpenMRS ModuleResourcesServlet has Path Traversal that Leads to Arbitrary File Read

• Maven org.openmrs.web:openmrs-web: <= 2.7.8 (no fix yet) • Maven org.openmrs.web:openmrs-web: >= 2.8.0, < 2.8.6 → fixed in 2.8.6

Affected Versions version ≤ 2.7.8 (latest version at time of disclosure) https://github.com/openmrs/openmrs-core Impact The `/openmrs/moduleResources/{moduleid}` endpoint in OpenMRS Core is vulnerable to a path traversal attack. The `ModuleResourcesServlet` does not properly validate user-supplied path input, allowing an attacker to traverse directories and read arbitrary files from the server filesystem (e.g., `/etc/passwd`, application configuration files containing database credentials). This endpoint serves static module resources (CSS, JS, images) and is not protected by authentication filters, as these resources are required for rendering the login page. Therefore, this vulnerability can be exploited by an unauthenticated attacker. > Note: Successful exploitation requires the target deployment to run on **Apache Tomcat Steps to Reproduce 1. Identify a valid installed module ID on the target OpenMRS instance (e.g., `legacyui`). 2. Send the following HTTP request: 3. The server responds with HTTP 200 and the contents of `/etc/passwd`: Root Cause Analysis The vulnerability exists in `ModuleResourcesServlet.java` (`web/src/main/java/org/openmrs/module/web/ModuleResourcesServlet.java`). The `getFile()` method constructs a filesystem path from user-controlled input without performing path boundary validation: ```java protected File getFile(HttpServletRequest request) { // Step 1: User-controlled path input String path = request.getPathInfo(); // Step 2: Extract module from path prefix Module module = ModuleUtil.getModuleForPath(path); if (module == null) { return null; } // Step 3: Strip module ID prefix — no traversal check String relativePath = ModuleUtil.getPathForResource(module, path); // Step 4: Concatenate into absolute path String realPath = getServletContext().getRealPath("") + MODULE_PATH + module.getModuleIdAsPath() + "/resources" + relativePath; // contains "/../../../etc/passwd" realPath = realPath.replace("/", File.separator); // Step 5: No normalize().startsWith() boundary check File f = new File(realPath); if (!f.exists()) { return null; } return f; // Arbitrary file returned to client } ``` The helper method `ModuleUtil.getPathForResource()` only strips the module ID prefix and performs no sanitization: ```java public static String getPathForResource(Module module, String path) { if (path.startsWith("/")) { path = path.substring(1); } return path.substring(module.getModuleIdAsPath().length()); // Returns unsanitized remainder, e.g., "/../../../../../../etc/passwd" } ``` The resulting path resolves as: ``` {webapp}/WEB-INF/view/module/legacyui/resources/../../../../../../etc/passwd → /etc/passwd ``` Notably, the same codebase already implements correct path traversal protection in `StartupFilter.java`: ```java // StartupFilter.java — correct protection fullFilePath = fullFilePath.resolve(httpRequest.getPathInfo()); if (!(fullFilePath.normalize().startsWith(filePath))) { log.warn("Detected attempted directory traversal..."); return; // Request rejected } ``` This check is absent from `ModuleResourcesServlet`. Remediation Add a path boundary check after constructing `realPath` and before returning the `File` object. The fix should use `normalize()` + `startsWith()` to ensure the resolved path stays within the allowed module resources directory: ```java File f = new File(realPath); Path allowedBase = Paths.get(getServletContext().getRealPath(""), "WEB-INF", "view", "module"); if (!f.toPath().normalize().startsWith(allowedBase.normalize())) { log.warn("Blocked path traversal attempt: {}", request.getPathInfo()); return null; } ``` This is consistent with the existing pattern used in `StartupFilter.java` and `TestInstallUtil.java` within the same project.