When built for native Windows (MinGW-w64 or MSVC), the command line tools from XZ Utils 5.6.2 and older have a command line argument injection vulnerability. Command line tools built for Cygwin or MSYS2 are unaffected. liblzma is unaffected.
If a command line contains Unicode characters (for example, filenames) that don't exist in the current legacy code page, the characters are converted to similar-looking characters with best-fit mapping. Some best-fit mappings result in ASCII characters that change the meaning of the command line, which can be exploited with malicious filenames to do argument injection or directory traversal attacks.
This issue was discovered by Orange Tsai and splitline from DEVCORE Research Team.
XZ Utils 5.6.3 (and the backported commits in the v5.4 and v5.2 branches) force the process code page to UTF-8. This avoids best-fit mappings and thus fixes the issue. However, forcing the process code page to UTF-8 is possible only on Windows 10 version 1903 and later. The command line tools remain vulnerable if used on an old older version of Windows.
A related smaller issue remains: Windows filenames may contain unpaired surrogates (invalid UTF-16). These are converted to the replacement character U+FFFD in the UTF-8 code page. Thus, filenames with different unpaired surrogates appear identical and aren't distinguishable from filenames that contain the actual replacement character U+FFFD.
Compatibility notes:
-
UTF-8 is now the expected encoding of the file lists read using --files and --files0 options when running on Windows 10 version 1903 or later.
-
If building with a MinGW-w64 toolchain, it is recommended to use UCRT version instead of the old MSVCRT. With the UTF-8 code page, messages with non-ASCII characters are not shown properly with MSVCRT.
splitline Finder
When built for native Windows (MinGW-w64 or MSVC), the command line tools from XZ Utils 5.6.2 and older have a command line argument injection vulnerability. Command line tools built for Cygwin or MSYS2 are unaffected. liblzma is unaffected.
If a command line contains Unicode characters (for example, filenames) that don't exist in the current legacy code page, the characters are converted to similar-looking characters with best-fit mapping. Some best-fit mappings result in ASCII characters that change the meaning of the command line, which can be exploited with malicious filenames to do argument injection or directory traversal attacks.
This issue was discovered by Orange Tsai and splitline from DEVCORE Research Team.
XZ Utils 5.6.3 (and the backported commits in the v5.4 and v5.2 branches) force the process code page to UTF-8. This avoids best-fit mappings and thus fixes the issue. However, forcing the process code page to UTF-8 is possible only on Windows 10 version 1903 and later. The command line tools remain vulnerable if used on an old older version of Windows.
A related smaller issue remains: Windows filenames may contain unpaired surrogates (invalid UTF-16). These are converted to the replacement character U+FFFD in the UTF-8 code page. Thus, filenames with different unpaired surrogates appear identical and aren't distinguishable from filenames that contain the actual replacement character U+FFFD.
Compatibility notes:
UTF-8 is now the expected encoding of the file lists read using
--filesand--files0options when running on Windows 10 version 1903 or later.If building with a MinGW-w64 toolchain, it is recommended to use UCRT version instead of the old MSVCRT. With the UTF-8 code page, messages with non-ASCII characters are not shown properly with MSVCRT.