> [!warning] AI-Generated Vulnerability Report > This report was produced using AI-assisted security analysis, adversarially verified but not human-confirmed. This finding was challenged against the codebase and survived; we filter out low-confidence results rather than forwarding raw model output. Technical details, exploitability, and severity may still be wrong. Please validate independently before acting. <details open> <summary><strong>Basic information</strong></summary> **Project name:** Eclipse Kura **Project id:** iot.kura **Repository:** https://github.com/eclipse-kura/kura-management-ui </details> <details> <summary><strong>What are the affected versions?</strong></summary> All commits on `develop` up to and including `1767d7650dad7026996a6c95e14ef529ac755ac3` (2026-04). The same logic exists in the upstream `eclipse-kura/kura` `org.eclipse.kura.web2` bundle. </details> <details open> <summary><strong>Summary</strong></summary> The "Command" file-upload handler at `POST /admin/denali/file/command` extracts a client-supplied ZIP archive into the configured `command.working.directory`. The path-containment check `validateFileName()` compares canonical paths with `String.startsWith()` **without appending a trailing path separator**, so an entry that canonicalises to a *sibling* directory sharing the same string prefix (e.g. `/tmpevil/x` when the intended directory is `/tmp`) is accepted. The handler then calls `parent.mkdirs()` and `new FileOutputStream(newFile)`, creating directories and writing attacker-controlled bytes outside the intended extraction root. </details> <details> <summary><strong>Severity</strong></summary> **Low.** Preconditions are significant: the attacker must already hold an authenticated web-console session with the `kura.device` permission and a valid per-session XSRF token. The escape is also constrained — it does **not** grant arbitrary filesystem write, only writes to paths whose canonical form has the working directory's canonical path as a string prefix. With the default fallback working directory `/tmp`, the reachable set is `/tmp*` siblings (e.g. `/tmpfoo/…`), which are not normally security-sensitive on a stock Linux filesystem. Concrete escalation depends on the operator's choice of `command.working.directory` and what sibling-prefix paths exist or are useful in that deployment. The `kura.device` role already permits writing arbitrary files *into* the working directory and starting/stopping arbitrary OSGi bundles via `GwtDeviceService`, so the marginal privilege gained by this bug is small. It does, however, breach the explicit security boundary the code is trying to enforce, and on Kura deployments where the JVM runs as root (the common case for an IoT gateway managing network interfaces) `mkdirs()` will succeed at the filesystem root. </details> <details> <summary><strong>Weakness (CWE)</strong></summary> - **CWE-22** — Improper Limitation of a Pathname to a Restricted Directory ("Path Traversal") - Variant: partial-path traversal / zip-slip via prefix-match without separator </details> <details> <summary><strong>Location</strong></summary> `bundles/org.eclipse.kura.web2/src/main/java/org/eclipse/kura/web/server/servlet/FileServlet.java` - `doPostCommand` extraction loop: lines **344–380** - Vulnerable validator: `validateFileName`, lines **410–422** ```java private String validateFileName(String zipFileName, String intendedDir) throws IOException, GwtKuraException { File zipFile = new File(zipFileName); String filePath = zipFile.getCanonicalPath(); File iD = new File(intendedDir); String canonicalID = iD.getCanonicalPath(); if (filePath.startsWith(canonicalID)) { // <-- no trailing File.separator return filePath; } else { throw new GwtKuraException(GwtKuraErrorCode.ILLEGAL_ACCESS); } } ``` Caller (lines 348–362): ```java String expectedFilePath = new StringBuilder(localFolder.getPath()).append(File.separator) .append(ze.getName()).toString(); String fileName = validateFileName(expectedFilePath, localFolder.getPath()); File newFile = new File(fileName); ... if (newFile.getParent() != null) { File parent = new File(newFile.getParent()); parent.mkdirs(); } FileOutputStream fos = new FileOutputStream(newFile); ``` </details> <details> <summary><strong>Origin</strong></summary> The `validateFileName` helper predates this repository — it was inherited from the upstream `eclipse-kura/kura` web UI when `kura-management-ui` was split out. `git log -- "**/FileServlet.java"` in this repository shows the file arriving in the initial packaging migration (commit `ec7ffbc`, "Migrated artifact to rpm/deb packaging system (\#1)") with the bug already present; subsequent commits did not touch the validator. </details> <details> <summary><strong>Methodology</strong></summary> 1. Enumerated all servlet registrations in `Console.java` and classified each by `ServletContextHelper` (`resourceContext` = unauthenticated, `sessionContext` = authenticated) to map the trust boundary. 2. Focused on multipart/file handlers reachable post-auth: `FileServlet`, `DeploymentAgentFileServlet`, `LogServlet`, `DeviceSnapshotsServlet`, `ChannelServlet`. 3. For each ZIP/archive code path, inspected the entry-name → filesystem-path construction and the containment check. 4. Wrote a standalone Java program replicating `validateFileName` byte-for-byte and the surrounding `doPostCommand` loop, fed it a crafted ZIP, and observed the result. 5. Searched `git log --grep` and GitHub issues/PRs in both `eclipse-kura/kura-management-ui` and `eclipse-kura/kura` for prior reports ("zip slip", "validateFileName", "traversal", "FileServlet") — none found. </details> <details> <summary><strong>Validation</strong></summary> Two standalone reproductions were compiled and run, mirroring the exact `validateFileName` body and the `doPostCommand` extraction loop. ### Repro 1 — default fallback working directory `/tmp` (non-root process) ```text $ javac ZipSlipRepro.java && java ZipSlipRepro [+] Wrote malicious zip: /tmp/malicious.zip [*] Processing entry: ../tmpevil/pwned.txt expectedFilePath = /tmp/../tmpevil/pwned.txt validateFileName -> ACCEPTED: /tmpevil/pwned.txt parent.mkdirs() -> /tmpevil (exists=false) Exception in thread "main" java.io.FileNotFoundException: /tmpevil/pwned.txt (No such file or directory) at java.io.FileOutputStream.open0(Native Method) ... ``` The validator **accepts** `/tmpevil/pwned.txt` for intended dir `/tmp`. The `FileOutputStream` only fails because the test process is unprivileged and cannot create `/tmpevil` at the filesystem root; on a typical Kura gateway the JVM runs as root and `mkdirs()` would succeed. ### Repro 2 — full chain under a user-writable parent ```text $ javac ZipSlipRepro2.java && java ZipSlipRepro2 [+] command.working.directory = /tmp/kura-repro/work [*] entry=../work-escaped/pwned.txt expectedFilePath=/tmp/kura-repro/work/../work-escaped/pwned.txt validateFileName ACCEPTED -> /tmp/kura-repro/work-escaped/pwned.txt WROTE: /tmp/kura-repro/work-escaped/pwned.txt === RESULT === intendedDir = /tmp/kura-repro/work escaped file exists? true at /tmp/kura-repro/work-escaped/pwned.txt escaped file is inside intendedDir? false [!] VULNERABILITY CONFIRMED: wrote outside intendedDir ``` A control entry `../etc/pwned` is correctly **rejected** (`ILLEGAL_ACCESS`), confirming the bug is specifically the missing-separator prefix match, not a total absence of validation. ### Reproduction source ```java // validateFileName copied verbatim from FileServlet.java:410-422 private static String validateFileName(String zipFileName, String intendedDir) throws IOException { File zipFile = new File(zipFileName); String filePath = zipFile.getCanonicalPath(); File iD = new File(intendedDir); String canonicalID = iD.getCanonicalPath(); if (filePath.startsWith(canonicalID)) { return filePath; } else { throw new RuntimeException("ILLEGAL_ACCESS"); } } // driver: build zip with entry "../tmpevil/pwned.txt", then replay // FileServlet.java:348-369 against workingDir="/tmp" ``` </details> <details> <summary><strong>Detail</strong></summary> `doPostCommand` (line 298) handles `POST /admin/denali/file/command`. Dispatch in `doPost` (line 194–196) gates it behind `KuraRemoteServiceServlet.requirePermissions(req, Mode.ALL, new String[]{KuraPermission.DEVICE})` and the body itself re-checks the XSRF token from the multipart form field (lines 311–316). The servlet is registered under the authenticated `sessionContext` in `Console.java`, so the full session-handler chain (`BaseSecurityHandler` → `SessionAutorizationSecurityHandler` → `SessionExpirationSecurityHandler` → …) runs first. The working directory comes from the `PasswordCommandService` OSGi service property `command.working.directory` (line 322), falling back to `System.getProperty("java.io.tmpdir", "/tmp")` if unset, empty, or not a directory (lines 323–325). On a packaged Linux install `java.io.tmpdir` is `/tmp`. For each `ZipEntry`, the code builds `localFolder.getPath() + File.separator + ze.getName()` and passes it to `validateFileName` together with `localFolder.getPath()`. The validator canonicalises both and tests `filePath.startsWith(canonicalID)`. Because `getCanonicalPath()` of a directory does **not** include a trailing separator, `"/tmpevil/x".startsWith("/tmp")` is `true`. The accepted path is then handed to `new File(...)`, `parent.mkdirs()`, and `new FileOutputStream(...)`. **Input sources to the sink** (enumerated): the only caller of `validateFileName` is `doPostCommand`; the only data flowing into its first argument is `ze.getName()` from the uploaded archive; the second argument is operator/system configuration. There is no other code path into this validator. </details> <details> <summary><strong>Other patterns examined and ruled out</strong></summary> These were investigated as candidate findings and determined not to cross a meaningful trust boundary. Listed for completeness. | Sink | Why ruled out | |---|---| | `SkinServlet.checkFile()` (unauthenticated `/admin/denali/skin/*`) | Iterates `Files.list(styleDir)` (direct children only) and matches by `getAbsolutePath().endsWith(resourceName)`; cannot escape the directory regardless of `../` in the request. | | `GwtPackageServiceImpl.installPackageFromMarketplace()` / `sendSuccessFeedbackToMarketplace()` — client-supplied `dpUrl` → `installDeploymentPackageAsync`, client-supplied URL → outbound HTTP | Requires `kura.packages.admin`, which by design grants arbitrary OSGi bundle install (= RCE-equivalent). No privilege escalation. | | `ChannelServlet`:72 `Content-Disposition: attachment; filename=asset_<assetPid>.csv` with raw `req.getParameter("assetPid")` | Jetty's `HttpFields` rejects CR/LF in header values (`IllegalArgumentException`). Requires `kura.wires.admin`. | | `LogServlet` `journalctl -u <unit>` with `setExecuteInAShell(true)` | `<unit>` values come from system property `kura.log.download.sources` (operator config), not request input. Cookie `LogsDownload-<nonce>` uses request-supplied `nonce` in the *name* but value is the constant `"finished"`; Jetty validates cookie names per RFC 6265. | | `WiresBlinkServlet`:180 `Access-Control-Allow-Origin: *` on SSE endpoint | Endpoint is behind the authenticated `sessionContext`; browsers do not send credentials on `*`-origin CORS, so a cross-origin page cannot ride the victim's session. | | OSGi LDAP-filter concatenation: `GwtDriverAndAssetServiceImpl.java:287`, `GwtServerUtil.java:676`, `GwtComponentServiceInternal.java:509`, `FilterUtil.java:30` — `"(kura.service.pid=" + userPid + ")"` | Filter is always scoped to a fixed service class (`Driver.class`, `WireComponent.class`, …) by `BundleContext.getServiceReferences(Class, filter)`; injected clauses cannot widen the class. Result is used only to read channel/component metadata. Requires `kura.wires.admin` or `kura.admin`. | | `RoutingSecurityHandler` matching on raw `request.getRequestURI()` against `Set::contains` of literal paths | Jetty normalises `..`/`//`/`%2e` before dispatch; the predicate is exact-match, not prefix-match, so `/admin/login/password/../../denali/file` does not satisfy `equals("/admin/login/password")`. | | `DeviceSnapshotsServlet` / `GwtSnapshotServiceImpl` snapshot download | Snapshot ID is parsed as `long` and passed to `ConfigurationService.getSnapshot(long)`; no path construction. Requires `kura.admin`. | --- **Verification verdict:** TRUE POSITIVE ### Verification details The full extraction chain is now confirmed end-to-end: the verbatim `doPostCommand` loop (`validateFileName` → `new File` → `parent.mkdirs()` → `FileOutputStream`) wrote attacker bytes to a **sibling** directory outside the working root, while the `../../etc/pwned` control was rejected. Here is the completed verification. </details> <details> <summary><strong>Verification Report: Partial Zip-Slip in `FileServlet.doPostCommand`</strong></summary> **VERDICT: TRUE POSITIVE** — bounded partial path traversal (sibling-prefix directory escape) via missing separator in the containment check; Low severity is correct. EXPOSURE: AUTHENTICATED — the attacker needs a valid web-console session whose user holds `kura.device` (or `kura.admin`) plus a matching per-session XSRF token to POST the crafted archive to `/admin/denali/file/command`. SCOPE: PRODUCTION — `kura-management-ui` is the shipped administrative web console for Eclipse Kura IoT gateways (README: "Eclipse Kura™ Web UI"); no doc marks it dev-only or out of scope, and `FileServlet` is registered under the authenticated `sessionContext` in `Console.java:537`. No EOL/deprecation/successor banner found in README or CONTRIBUTING. ### Phase 1 — Data Flow - **Source:** `ze.getName()` — the entry name of a ZIP uploaded via multipart to `/admin/denali/file/command` (`FileServlet.java:344-349`). Attacker-controlled. - **Transform:** `expectedFilePath = localFolder.getPath() + File.separator + ze.getName()`. `ZipInputStream` performs **no** normalization of entry names, so `../…` survives verbatim (confirmed by reading the loop and by PoC). - **Sink / check:** `validateFileName` (`:410-422`) canonicalises the path (collapsing `../`) and then tests `filePath.startsWith(canonicalID)` **with no trailing separator**. Accepted paths flow to `new File(fileName)` → `parent.mkdirs()` (`:357-360`) → `new FileOutputStream(newFile)` (`:362`). - **Trust boundaries (2):** network→servlet (crossed by the authenticated session) and archive-content→filesystem-path. The permission gate `requirePermissions(…DEVICE)` (`:195`) and `checkXSRFToken` (`:313`) are genuinely enforced — `requirePermissionsInternal` validates the session's authorized-user attribute and the user's permission config, so this is not pre-auth. Two boundaries, straightforward flow → standard verification is appropriate. - No framework/environment protection intervenes: entry names are not sanitized by `java.util.zip`, and canonicalisation happens *before* the flawed prefix test (it is what enables the escape, not what prevents it). ### Phase 2 — Exploitability - **Attacker control: CONFIRMED.** The entire first argument to the validator derives from `ze.getName()`, fully attacker-chosen. - **"Bounds" analysis (prefix reachability): CONFIRMED and bounded.** The accepted set is exactly the canonical paths that string-start-with `canonicalID`. For default `/tmp`, that is `/tmp` itself and any `/tmp*` sibling (`/tmpevil/…`). It is *not* unbounded: `/tmp/../tmp2/../../etc/passwd` canonicalises to `/etc/passwd`, which does **not** start with `/tmp` and is rejected — so the primitive cannot be chained to arbitrary paths. Empirically verified: `../tmpevil/pwned.txt` accepted, `../etc/pwned` and `../../etc/pwned` rejected. - **Race conditions: N/A** — single-threaded per-request extraction, no TOCTOU in the check→use window. ### Phase 3 — Impact Real security impact: a write **outside** the intended extraction root — a genuine breach of the containment boundary this code exists to enforce (CWE-22), not merely an operational-robustness issue. It is bounded to sibling-prefix directories, so it is not arbitrary filesystem write and there is no generic RCE from this primitive alone; concrete escalation depends on the operator's `command.working.directory` and whether the JVM runs as root (common on a gateway, where `mkdirs()` succeeds at the filesystem root). `validateFileName` is the **primary** containment control here (not defense-in-depth), so its failure is the vulnerability itself. This supports the reported **Low** rating. ### Phase 4 — PoC (executable, run under JDK 21) Replaying the `doPostCommand` loop + `validateFileName` verbatim against a real ZIP: - **Positive:** working dir `…/work`, entry `../work-escaped/pwned.txt` → file written to `…/work-escaped/pwned.txt` — **outside** the working dir (`inside working dir? false → VULNERABILITY CONFIRMED`). The full `mkdirs()` + `FileOutputStream` write executed. - **Negative:** entry `../../etc/pwned` → `ILLEGAL_ACCESS` (correctly rejected), proving the defect is specifically the missing-separator prefix match, not absent validation. ### Phase 5 — Devil's Advocate (13-item checklist + 7 questions) 1. Full validation chain traced — `validateFileName` is the only check; no upstream normalization. 1a. Conditional flow imposes no bound that prevents the sibling case (PoC proves reachability). 2. Not defensive-programming confusion — the "check" is genuinely bypassable. 3. Exploitable data path confirmed by executable PoC. 4. Source is attacker-uploaded archive content. 5. Prefix-reachability analyzed algebraically and empirically (bounded, but non-empty). 6. No TOCTOU claimed. 7. API contract: `ZipInputStream` does not normalize names; `File.getCanonicalPath()` has no trailing separator — the root cause. 8. `ze.getName()` is external input, not trusted internal storage. 9. Not pattern-matching — bypass demonstrated. 10. No concurrency. 11. Real impact (boundary breach), correctly capped at Low. 12. Primary control, not defense-in-depth. 13. Checklist applied per-item. Seven questions: (1) not pattern bias — empirically shown; (2) trust boundary correct — attacker controls the entry name; (3) reachability proven; (4) primary control, not DiD; (5) not hallucinated — code read directly and PoC run; (6) not dismissing — escape confirmed despite bounded impact; (7) no invented mitigation — I re-read `validateFileName`, `doPost`, `requirePermissions`, and the servlet registration to confirm the gates and the flaw as stated. ### Phase 6 — Gate Review | Gate | Result | Evidence | |---|---|---| | 1. Process | **PASS** | All phases documented with code refs + executable PoC. | | 2. Reachability | **PASS** | Authenticated `kura.device` user; `ze.getName()` attacker-controlled; PoC confirms. | | 3. Real Impact | **PASS** | Write outside intended dir = CWE-22 boundary breach (bounded; Low). | | 4. PoC Validation | **PASS** | Positive PoC writes outside root; negative PoC rejected. | | 5. Math/Bounds | **PASS** | Prefix reachability set is non-empty (`/tmp*` siblings) yet bounded — vulnerable condition provably occurs. | | 6. Environment | **PASS** | No framework/OS protection blocks it; canonicalisation precedes the flawed test. | All six gates pass. ### Conclusion The report is accurate, including its honest, bounded severity assessment. The root cause is `filePath.startsWith(canonicalID)` without a trailing `File.separator` in `validateFileName` (`FileServlet.java:417`), letting a canonicalised sibling-prefix path (e.g. `/tmpevil/…` for working dir `/tmp`) pass the containment check and be written by the extraction loop. The suggested fix (compare against `canonicalID + File.separator`, or use `Path.startsWith` on normalized `Path` objects) is correct. </details> <details> <summary><strong>Steps to reproduce</strong></summary> 1. Authenticate to the web console as any identity holding `kura.device` (or `kura.admin`, which implies all permissions). 2. Fetch the XSRF token via the `GwtSecurityTokenService` GWT-RPC endpoint, or simply load `/admin/denali` and read it from the page state — it is the session attribute `xsrf.token` and is echoed to the client. 3. Craft a ZIP whose entry name traverses to a sibling-prefix directory of the target's `command.working.directory`. Example for the default `/tmp`: **Proof of concept:** [poc.py](/uploads/62c43dabf53de620cb6b2cb135bf402d/poc.py) 4. POST it as multipart to `/admin/denali/file/command` with form field `xsrfToken=<token>` and the session cookie. 5. Server creates `/tmpevil/` and writes `/tmpevil/pwned.txt` (assuming the JVM user can `mkdir` at that location — true when Kura runs as root). Practical impact ceiling: depends on `command.working.directory`. If an operator configures it as e.g. `/opt/eclipse/kura/data`, the reachable set is `/opt/eclipse/kura/data*`; if `/var`, the reachable set is `/var*`. There is no generic path to RCE from this primitive alone — it is a building block whose value is deployment-specific. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> Append the platform separator before comparing, and accept the exact directory itself: **Suggested fix:** [fix-1.java](/uploads/bb16cdd121a1fa5690289f3a6f85e424/fix-1.java) A more robust alternative is to use `java.nio.file.Path` normalisation: **Suggested fix:** [fix-2.java](/uploads/01a83575b8fa321091f9ca43bcdb1f03/fix-2.java) `Path.startsWith(Path)` compares path *components*, not string prefixes, so `/tmpevil` does not start with `/tmp`. <!-- l1-helper-dup: d2edc0613ec0a163dc0261a223a1e7e8f67581e5865e8ea2dcb5e89f10863a18 --> </details>