>>>I don't understand.
>>>
>>>Sounds to me like the malware is already loaded deep into the machine if it's looking through folders for an out of date zip DLL.
>>>
>>>What's it going to do create zipped up copies of itself and disperse them to everyone on the network?
>>>
>>>Again, I think the malware is already on the machine. And from it's known servers that it downloads additional components it can surely download some kind of zip code malware maker.
>>>
>>>The folder that the application in question is in Program Files or something?
>>
>>I do get your point about the fact, when there is an attacker searching for dll libraries on my file system, there must be something serious already going, and the security is already compromised.
>>
>>I am not saying there is any malware present at that moment, but I want to avoid that our program and the files we are distributing to our client can create a security risk on their system. We just recently changed our compression methods to use 7zip, because of large files that we can run in the 64bit version. (Previously we used Dynazip for this). But we got worried since we distribute the 7zip libraries through our setup to the client, and we are aware that there have been upgrade of 7zip in the past because of security flaws.
>>
>>Therefore I had the question if there is any security risk of having an outdated dll or executable, which has a security flaw, present on the machine. The dll itself does not contain a virus, but how does an attacker exploit the vulnerability of a program? It makes more sense to me if the OS itself has a security flaw. Let's imagine, a user receives an email with a Word Document that contains a VB script macro, and this runs some code. It can even access network resource that the current user has access to. So why would that virus need any other program like 7zip.dll to do anything, since it's already doing it's work. The only thing I can imagine, it poses itself into another process to gain elevated access, but I don't know much about this.
>>
>>For example C:\MyApp\Extlib\7z\x64\7z.dll, or C:\Program Files (x86)\MyApp\Extlib\7z\x64\7z.dll , if the existence of this file would mean, that a vulnerability in this dll can be exploited by an attacker. 7zip has previously been upgraded several times, after vulnerabilities have been found, so I take that as an example.
>>
>>That would mean that we would need to regularly make sure that the third party libraries are updated at our client's systems, as well as our responsibility to inform them about security risks if any vulnerabilities have been reported. And what if we do not inform them on time, or if we do provide an upgrade with the latest releases, however the client would fail to distribute this update on their machines, and we have not specifically pointed out which files and which security risks there exist.
>>
>>If you would install 7zip the regular way, and start the program directly, it would check for upgrades online and inform you, that there is a new version available for download (like most other programs do). If the user would ignore those messages, and an attacker would exploit this application's vulnerability, it would then be the fault of the user. Furthermore, the admin can create a list of all installed applications on their clients, and make sure that any of these applications are up-to-date. But the admin would not be aware of any resources our program is using internally, because that would not be in their report. So we basically sneak a program onto their system and usually do not tell them which separate resources we install, up to now nobody was really interested. Actually a few admins now ask which files need to be installed and registered, but that usually only for those files that must be registered in the registry. (because they distribute through the domain).
>>
>>However we can't check for upgrades for all our third party libraries or expect the users/admins to know all external resources our program is using and checking for any updates of those. Even for our distribution setup, we cannot always be up-to-date with all third party libraries, at least we have never bothered to do so up to now. It would be a very tedious work, for instance we distribute a dynazip library that is probably well over 10 years old and never bothered to update this, because it is working well. So would that mean each time before building a setup, we need to check on the 7zip website for updates, and any fixed security flaws, to make sure we have the latest version? And if there are issues mentioned in their upgrade log, do we need to inform all admins who have installed our software? AFAIK nobody is doing this in practice.
>>
>>There hasn't been a case yet where anything happened, but it is a situation of a possible liability, because we let the client install our software which could contain dll files that may be exploited by an attacker. Imagine it turns out your software's third party resources were used by a ransomware attack, I don't know what kind of liability you could find yourself in, especially if this resource has already been updated and you failed to implement the latest version of it, or failed to inform the admin that you distribute this resource. The liability question itself is out of scope, I am only looking at theoretical scenarios.
>>
>>Therefore my question, if there is a third party resource like this in our program folder that we installed, and it contains a vulnerability, if that can be exploited just because it is on the file system. I was always under the blissful impression that it must be a program that is installed and run by the user directly in order to be explited, but the only difference would be that there is a registry entry for the installed program, so technically there no real difference between an installed application and a library that we copy through our setup.
>>
>>The more secure way of using those resources would then be to have them boxed inside our application, that they do not reside on the file system of the client, which would minimize any possibility of exploiting by an attacker.
>
>Christian,
>
>First, I'm not the total security expert here. I'm just voicing my ideas or opinions, but I think we can all agree that if some process on the computer is actively looking for the 7Zip DLL in folders other than the 7Zip Program Files folder that the machine is pretty much compromised.
>
>I researched a little and found some interesting websites:
>
>https://www.cvedetails.com/ is one of many.
>
>I suspect that the 7Zip gets exploited by unzipping a crafted zipped up file. Just a guess. If your app's 'private' DLL only Zips files up and does not unzip external zipped up files then, IMO, there is little risk. But like I said, I'm not an expert on this matter.
>
>I did run my 7Zip and went into Help About and other places to see if there was an Update option. No, there is no automatic update option of 7Zip and my version was way out of date. I had to go to the 7Zip website and download a new version.

Thanks for looking into that. It makes sense what you are saying. We do unzip archives that have been built by our own application, but we could see if we can verify if that zip file was created by our program before allowing to unzip the archive to minimize a user error.