[German]Another information for users of the packing program 7-Zip. The developer of the software has updated the Windows version of the program available for various platforms to version 18.05 to close a security hole. Time for a closer look.
Some words about version 18.05
Version 18.05 was updated on April 30, 2018 according to the 7-zip.org page. The sourceforge.net page is rather imprecise regarding the changes and only lists changes after 7-Zip version 18.01. In addition to a problem with Windows 10 with’Large Pages’, which is said to have been fixed, the author claims to have fixed the CVE-2018-10115 vulnerability in the RAR unpack code. The change log deals with changes after 7-Zip version 18.01 an.
The discussion on sourceforge.net is more interesting. The installer won’t work on Windows 10 Version 1803. Another user notes that the Linux version has stopped at version 16.02. This would mean that some security holes in the RAR code are still unfixed..
Details about CVE-2018-10115
The CVE database doesn’t contains details about CVE-2018-10115. But we know, that CVE-2018-10115 is related to 7-zip. But was the issue? Here you can find details again in Dave’s landave blog. His article 7-Zip: From Uninitialized Memory to Remote Code Execution describes a problem in the UnRAR code used in 7-zip. And the UnRAR libraries are a mine field in terms of security. Some time ago information about similar security flaw was mentioned in the landave blog (see my blog article 7-Zip vulnerable – update to version 18.01).
The new error occurs in connection with the handling of solid compression in the UnRAR part of the program. Dave reveals the technical details in his blog post. The problem: It cannot always be ensured that certain variables are initialized when unpacking RAR archives. An uninitialized memory can lead to a heap-based buffer overflow in memory. And such a memory overflow potentially carries the risk that this can be exploited for remote code execution. In English: If it runs badly, a prepared RAR archive file is enough to trigger this buffer overflow and possibly attack the system.
The general problem with 7-Zip
Already in the blog article Security-Risk: Avoid 7-Zip I had pointed out a problem with 7-Zip. Up to version 18.00 (beta), the 7-Zip developer ships his software without support for DEP and ASLR in 7-Zip. Shortly after the release of the above blog post, Igor Pavlov released 7-Zip 18.01 with /NXCOMPAT flag enabled to enable DEP on all platforms.
Furthermore, all dynamic libraries (7z.dll, 7-zip.dll, 7-zip32.dll) have set the /DYNAMICBASE flag and use a relocation table. Therefore, most of the running code is subject to ASLR.
All main programs (7zFM.exe, 7zG.exe, 7z.exe) come without /DYNAMICBASE and have a striped relocation table. This means not only they are not subject to ASLR, but you can’t even enforce ASLR with a tool like EMET or its successor, Windows Defender Exploit Guard. Of course, ASLR can only be effective if all modules are correctly randomized. Dave explicitly points this out in his article 7-Zip: From Uninitialized Memory to Remote Code Execution.
Within my blog post I received a comment from a reader. He used the source code of 7-Zip and compiled/linked it with flags NXCOMPAT and DYNAMICBASE. The results are interesting, the file sizes are not bigger than the original files.
The problem with the 7-Zip installer
Whoever thinks now: Great, I’m updating to 7-Zip version 18.05, so the security flaw CVE-2018-10115 is closed, should know the following. 7-Zip has a serious problem, which comes with the 7-Zip installer. This installer is vulnerable to DLL hijacking.
Background: The installer unpacks its setup*.exe files into a %Temp% directory, which can happen with normal user rights. To perform the installation, the installer then requests administrative privileges.
An attacker who has executed malware under a local default account only needs to detect this case. This can be determined using Win32 API calls. If 7-Zip creates a directory 7zS<abcd>.tmp during the update, the malware could be informed and then copy a fake file UXTheme.dll into this subdirectory. This file is called up as soon as the setup wizard is executed.
And thus the malware obtains administrative authorizations via this detour. Stefan Kanthak has pointed this out to me several times in connection with 7-Zip, Skype etc. Stefan Kanthak described this using the Mozilla installer on seclists.org as an example for a similar scenario.
Administrators in companies that use the usual deployment tools to roll out software updates are also not safe from this attack. Because the deployment tools typically run as a service under the SYSTEM account, and use %SystemRoot%\Temp\ to unpack.
With this in mind, I had recommended in the following blog posts to avoid using 7-Zip. Stupid, however, is that the 7-Zip functions are used in many products.