Open Adolph-WSY opened 1 month ago
First, are you using the command line tools (*.exe files like xz.exe) on Windows? The issue affects only those. If you only use liblzma, this issue is not relevant.
Even if you do use the command line tools, if you never pass untrusted filenames to them (for example, you only use the tools in a pipe) then the vulnerability isn't relevant.
Anyway, for 5.2.4, you can apply the commit 9ecccb3d5f67205f156f8c7ad1ec98436c165abd without the CMakeLists.txt part. 5.2.4 doesn't have CMake support. The changes to CMakeLists.txt were needed only for MSVC. Building the command line tools with MSVC isn't supported in 5.2.4.
The command line tools in 5.2.4 can be built for Windows only using MinGW or MinGW-w64 with help from MSYS or MSYS2 to run ./configure && make (possibly via windows/build.bash). The modifications to common_w32res.rc and the addition of w32_application.manifest are enough to apply the fix in this case. You don't even need the Makefile.am change, in fact, you might wish to omit that if building from a tarball and applying a patch because this way you avoid unneeded regeneration of the build system files.
@Adolph-WSY: Was the problem solved or is more information needed?
Thing is a bit strange
After installing the tool chain,
If I build directly using the 5.2.5 version source code downloaded from the official website, I can build the corresponding .exe.
but, if I cherry-pick the bug fix Commit 46ee0061629fb075d61d83839e14dd193337af59
to the v5.2.5 Tag, the compilation fails
` cd C:\devel
git clone https://github.com/tukaani-project/xz.git fix-5.2.5
cd fix-5.2.5
git checkout v5.2.5
git cherry-pick 46ee0061629fb075d61d83839e14dd193337af59
cd ..
Merge several files involved in cherry-pick into the source code decompressed from the official website tag.gz package
cd C:\devel\xz-5.2.5
bash windows/build.bash `
` checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Doxyfile config.status: creating Makefile config.status: creating po/Makefile.in config.status: creating lib/Makefile config.status: creating src/Makefile config.status: creating src/liblzma/Makefile config.status: creating src/liblzma/api/Makefile config.status: creating src/xz/Makefile config.status: creating src/xzdec/Makefile config.status: creating src/lzmainfo/Makefile config.status: creating src/scripts/Makefile config.status: creating tests/Makefile config.status: creating debug/Makefile config.status: creating src/scripts/xzdiff config.status: creating src/scripts/xzgrep config.status: creating src/scripts/xzmore config.status: creating src/scripts/xzless config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing po-directories commands config.status: creating po/POTFILES config.status: creating po/Makefile
NOTE:
liblzma will be thread unsafe due the combination
of --disable-threads --enable-small.
Making check in src
make[1]: Entering directory /c/devel/xz-5.2.5/src' cd .. && /bin/sh /c/devel/xz-5.2.5/build-aux/missing automake-1.16 --foreign src/Makefile /c/devel/xz-5.2.5/build-aux/missing: line 81: automake-1.16: command not found WARNING: 'automake-1.16' is missing on your system. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: <https://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <https://www.gnu.org/software/autoconf> <https://www.gnu.org/software/m4/> <https://www.perl.org/> make[1]: *** [Makefile.in] Error 127 make[1]: Leaving directory
/c/devel/xz-5.2.5/src'
make: *** [check-recursive] Error
`
Omit the Makefile.am change from the commit. When Makefile.am is changed (file timestamp is updated), the build system attempts to run automake-1.16 to update the corresponding Makefile.in. You could Automake it but it's waste of time if this is the only reason you would need it.
The Makefile.am change is there mostly so that the new files get included in a newly-created distribution tarball. Changing Makefile.am isn't needed to make the fix work.
It's the lines at the end of common_w32res.rc that do the actual work of including the manifest file in the executables.
@Adolph-WSY: Has this been solved? Did you manage to modify common_w32res.rc
and add the new file w32_application.manifest
and have a working build?
Thank you very much for fixing CVE-2024-47611: Argument injection on Windows in time. However, some of our products that cannot be upgraded are still using version 5.2.4 that has not switched the CMakefile build, which makes it impossible to apply the corresponding commit of the 5.2 branch for repair.
How should this vulnerability be fixed for versions 5.2.4 and earlier?