[German]Many users are knowing 7-Zip as a tool for unpacking archive files. The software is free of charge and is also available in a portable version for Windows. In addition, 7-Zip is also used in various products. Funny world? Unfortunately, there is a dark side of 7-Zip, because the tool is potentially a huge security risk. Here are some hints about what you should know – and a final piece of advice. Addendum: Newer versions of 7-Zip are using build options like ASLR and DEP.
Advertising
The problem with packers like 7-Zip
The core function of a program such as 7-Zip is unpacking of archive files, whereby various formats are to be supported. 7-Zip is quite good for that. The following figure shows the supported formats that can be associated to 7-Zip.
Unfortunately, there is a problem with this function: The content of the archive files to be unpacked (i. e. malware) could exploit vulnerabilities in 7-Zip & Co. to extract and execute malicious code. For this purpose, memory overflows must be provoked during unpacking, which can possibly be misused to execute the code. Or, to put it another way: The user tries to unpack a file, and a malware contained in the file becomes active and manipulates the files accessible under the user account. This is something no user expects from 7-Zip, but it is not unrealistic.
7-Zip and vulnerabilities
7-Zip is developed by Igor Pavlov and made available free of charge. That's generous, so it isn't easy to criticize. Unfortunately, security vulnerabilities in 7-Zip and the subordinate libraries with packing functions are found again and again. I recently posted the article
7-Zip vulnerable – update to version 18.01 about vulnerabilities in this tool and recommended an update to version 18.0 and higher. Igor Pavlov had reacted quickly after discovering the vulnerabilities and provided version 18.01 of 7-Zip. So far so good.
However, there are some scenarios where older versions of 7-Zip are used. And even third-party providers sometimes use 7-Zip (or sub-functions) in their programs. There older versions of the libraries or the program could be installed or updated on the system (without the user`s knowledge).
Advertising
This would be the' first thorn' in terms of security, although many users there, admittedly, are not aware of any of the dilemma' 7-Zip variant with security vulnerabilities working on my system' or have little or no influence on this issue.
If you need to use older, vulnerable 7-zip variants (why ever) on your system, you could fix the vulnerabilities CVE-2017-17969 and CVE-2018-5996 with micro-patches from 0patch.com (see their blog post). In the following consideration, however, I exclude this scenario because of its complexity.
Why 7-Zip puts you at risk
Let's get to the beef of this article. The developer of this tool refuse to hardening its software against unknown security vulnerabilities. To harden software with respect to the exploitability of unknown vulnerabilities, developers can specify different options when linking modules to an executable binary file. This Microsoft document introduces two such options for improving application security. There are other techniques (like compiler options to check for buffer overflow in executable code) of this kind, some of which have been known for many years.
Igor Patchev refuses since years to link 7-Zip binary files with the options /NXCOMPAT and /DYNAMICBASE. This means that 7-Zip runs on all Windows systems without ASLR. And DEP is enabled only on 64-bit Windows 7 systems and in the 32-bit version of Windows 10.
(Source: landave.io)
This has been described in landave's blog – and the image posted above shows, that DEP is deactivated permanently. The author of the linked blog post writes, that 7-Zip was compiled also without the /GS flag. So there are no checks for stack overflows. Beside the article in in landave's blog I know from another trustable security researcher, that Igor Pavlov has been informed about that potential security risks. Here is a zite from landave's blog post:
I have discussed this issue with Igor Pavlov and tried to convince him to enable all three flags. However, he refused to enable
/DYNAMICBASEbecause he prefers to ship the binaries without relocation table to achieve a minimal binary size. Moreover, he doesn't want to enable/GS, because it could affect the runtime as well as the binary size. At least he will try to enable/NXCOMPATfor the next release. Apparently, it is currently not enabled because 7-Zip is linked with an obsolete linker that doesn't support the flag.
And there's a problem with this: 7-Zip is free of charge, but its author uses outdated development tools and wants to save a few bytes in the program file at the expense of security. This leaves me with at this point to the recommendation, to avoid using this tool – until it's hardened against attacks to unknown vulnerabilities.
Addendum: This article has been written early 2018. Newer versions of 7-Zip are using nwo build options like ASLR and DEP. So the risks mentioned above, ware no longer valid (as long, as ASLR and DEP are active). To avoid DLL hijacking, I also recommend, not to use the 7-Zip .exe installer – use the .msi installer instead. In this case, and under the assumption, that the most recent 7-Zip version is used, it should be safe to use that tool.
Advertising
Many thanks for the heads-up. I am going to stop using, after many years use and will ask my colleagues to remove it also! It's a shame the developer prefers to save bytes and avoid secure techniques that are very simple to apply.
Are there any secure alternatives? I can get by with native unzipping for .zip files but other binaries will need a new tool or approach.
Mike
Currently the advise is to use the tools provides with the OS.
I compiled myself one with NXCOMPAT and DYNAMICBASE.
In the days to come, I'll find out if doing so had any drawbacks.
Thx for feedback. Let us know, if there is any drawback.
Well… I have a full time job and cannot test things fully. But, something very funny has happened:
I compiled 7-Zip 18.01 for x64 with /DYNAMICBASE /NXCOMPAT and the -GS+ switch (and I removed the -GS-) using Visual Studio 2017 Community edition (free). Here is what I got.
— 7zG.exe at 544 KB. Igor Pavlov's version is 548 KB, 4 KB larger
— 7zFM.exe at 748 KB. Igor Pavlov's version is 827 KB, 79 KB larger
— 7z.dll at 1525 KB. Igor Pavlov's version is 1618 KB, 93 KB larger
— 7z.exe at 470 KB. Igor Pavlov's version 445 KB, 25 KB small
— 7-zip.dll at 148 KB. Igor Pavlov's version is 74 KB, 50% of mine
— 7z.sfx at 341 KB. Igor Pavlov's version is 191 KB, 150 KB smaller
— 7zCon.sfx at 328 KB. Igor Pavlov's version is 172 KB, 156 KB smaller
Overall size increase: 229 KB.
I asked people who know C++. (I myself am a different type of developer. C# and JavaScript.) They say with proper optimizations, the size could drop. New Visual Studio version generate smaller files. Finally Visual Studio 2017 Community's license makes a generous exceptions for free and open-source apps like 7-Zip.
The worst thing about 7-zip is it has no digital certificate which is easy to get and people can help Igor pay for one if he doesn't want to create one of his own. I complained about this on the source code site. This means that when a virus gets on a system it loves to patch and hide inside the code since it will look unsigned before and after tampering. A great target since it is so heavily downloaded by sheeple (sheep people). There is no excuse for this nor is there any excuse for the above mentioned. Perhaps keeping all those security options out of the build even helps the tampering process to make patches to overrun buffers, etc. Think about. No digital certificate. Inexcusable. Should have been the first thing you talked about. In the real world, no one checks all of their app and DLL hashes hourly/daily to see if they have been tampered with (except the corporate world who takes security seriously and that corporation would fire someone for installing 7-zip).
'In the real world, no one checks all of their app and DLL hashes hourly/daily to see if they have been tampered with …'
That's the wrong asummption. It's a basic in programming, to assure, that a full qualified path is used to load the depending modules from trustable directories – Windows dlls are never located within the install or temp folders for instance. Even Microsoft's VS environments with .NET are providing such 'beginner fails'. That's the issue – not a digital signed 7-zip exe file – although it may be helpful, if the .exe is digitally signed.
Forget I said dlls for a moment. When an .exe with a digital certificate is patched it will no longer be a verified .exe (per digital certificate). This is a priceless tool. In contrast, 7-zip has no digital certificate. Therefore, I can't tell if the .exe was the same as that which was originally installed or if it was tampered with since it was installed since in both cases, it appears unverified. (Again, I assume I am not doing file or hash compares against known original versions/hashes). But with a digital certificate, I know it starts out verified and later if I see it is no longer verified, it must have been tampered with.
Bad actors leverage this as one of the many ways they hide behind something in the system. Hence they love very popular unsigned .exes — as soon as they land on your PC and see 7-zip, they hide in it among other ways they hide and then they remove traces of themselves. If 7-zip is detected as having been changed, so be it. They leverage that in most cases the change will go undetected.
Pingback: Open Source Code: Thousands of Eyes Constantly Improving It? | Ray Woodcock's Latest
What is the security status of 7zip at the end of 2021? Is there still vulnerabilities?
I was thinking of doing a cold storage of hdd encrypted with 7zip an no compression.
I didn't monitor this case anymore. If your system is clean, you can do your storage