The vulnerability exists in the junrar library's LocalFolderExtractor class, which is responsible for extracting files and directories from a RAR archive to the local filesystem. The root cause is the inconsistent handling of backslash (\) characters as path separators on non-Windows systems.
On Linux and other Unix-like systems, the backslash is a valid character in a filename, not a directory separator. The vulnerability is triggered as follows:
- A user attempts to extract a specially crafted RAR archive containing an entry with a path like
..\..\tmp\pwned.
- The
com.github.junrar.LocalFolderExtractor.createFile method is called to prepare the file for extraction.
- Inside
createFile, a security check is performed: f.getCanonicalPath().startsWith(destination.getCanonicalPath()). This check is intended to prevent files from being written outside the target extraction directory.
- However, on Linux,
getCanonicalPath() does not interpret the backslashes as separators and does not resolve the .. components. It sees ..\..\tmp\pwned as a single, literal filename. The check therefore passes, as the path appears to be inside the destination directory.
- The vulnerability description and patch indicate that the
makeFile method contained logic that explicitly split the filename by backslashes and reconstructed it using the system's separator (/ on Linux). This converted the seemingly innocuous filename into a malicious path (../../tmp/pwned). While the provided PoC involves writing a file (which doesn't directly call makeFile), the core flaw was the failure to normalize path separators before validation, which was fixed in createFile.
- Subsequently, when a
FileOutputStream is created using the path returned by createFile, the operating system correctly interprets the path, and the file is written outside the intended extraction directory, leading to an arbitrary file write.
The patch addresses this by introducing a helper method, invariantSeparatorsPathString, which replaces all backslashes with forward slashes. This normalization happens in createFile before the security check, ensuring that getCanonicalPath() can now correctly identify and block the path traversal attempt. The corresponding change in makeFile to split by / ensures consistent behavior for directory creation.
The identified vulnerable functions, com.github.junrar.LocalFolderExtractor.createFile and com.github.junrar.LocalFolderExtractor.makeFile, are the precise locations of the flawed validation and path construction logic. Any runtime profile during exploitation of this vulnerability would show these methods in the stack trace leading up to the arbitrary file write.
Miggo AI