7-Zip Flaws Reveal Soft Underbelly of the Software Supply Chain

Do you use 7-Zip?  Do you even know what it is?  One of the challenges that businesses and consumers have is that, like sausage, they often do not know what is in the software that they use.  As a result, they could be diligent about applying patches and still be exposed to hackers.

In this case, the product is 7-Zip.  7-Zip is a very popular free and open source file compression utility. Unfortunately, researchers at Cisco Talos have discovered two vulnerabilities that would allow malicious actors to execute arbitrary code with the same permissions as the user who runs the code.  If the program running the code is a system utility, it will have greater permissions than the average user, making the problem more concerning.

But here is the real problem.  Let’s assume that you are a diligent computer user and you apply all the patches that are available for your products.  However, you use some product – maybe open source, maybe commercial, that incorporates a third party library – in this case 7-Zip’s library – and that developer is not as diligent as the user.  They do not realize there is a problem and do not release an updated version of their product.  You, the diligent user, may still be vulnerable.  Even if you have applied all of the available patches.

In this case, 7-Zip is used by hundreds of products.  A quick Google search finds 7-Zip copyright notices for the backup software Commvault, the storage vendor EMC, the antivirus product Malwarebytes, the security product FireEye and many others.  Exactly how each of these vendors use 7-Zip and in which of their products is unknown, so any given user’s exposure is also unknown.

This is what I call the software supply chain problem.  As a software developer, whether in house for your company or as a commercial or open software developer, you need to understand precisely what versions of which third party code is incorporated into your software.  Worse yet, developers LOVE to scan public code repositories to find a routine to do some function instead of reinventing the wheel.  In that case, there is no one who is responsible for this piece of the software supply chain other that you, the developer who did the copy and paste.  Did you consider whether that piece of software was bug free?

Back to the 7-Zip problem.  It was caused by failing to check inputs to certain  functions to make sure that the inputs did not cause unintended consequences.  While the details are rather geeky, lack of validation of user input is possibly the single biggest source of security vulnerabilities that there is.  It is such a problem that hackers have invented an entire class of tools, called fuzzers, to detect and later exploit these problems.

OK, so I now understand the problem, what the heck do I do?

There are three answers to this question:

1. As a user, make sure that you understand every single software application installed on your system and check for and apply patches for each of them when they become available.  Unfortunately, tools like Windows Update DO NOT perform this function for you.  As a result, I generally recommend that users try to only install software that is REQUIRED.  Some users love to install any software that seems interesting.  The more software that you have, the more software that you have to monitor for patches.  As a corollary to this, for systems that process critical data like, say, credit cards or health information, this should be a rule and not a recommendation.
2. As a developer, you need to document the use of every piece of software that your team integrates into your product.  It does not matter whether that software is commercial, open source or from a code snippet library.  Then, for the rest of eternity (or at least for as long as that code is being used), you need to be diligent to watch for vulnerabilities and if you find them create and release patches.
3. As a purchaser of software, you should be asking vendors how they manage the software supply chain problem.  For one thing, it will give you a warm fuzzy (or not) that they are on top of this potentially critical problem.  For another, you may learn something that you can use internally in your company.

And the last thing to remember.  If you are using an old version of a product (like the millions of PCs running Windows XP, just as an example), it is likely that NO ONE is checking for security vulnerabilities.  You are fully on your own, guarding your machine.  Unfortunately, you are coming to a knife fight with a spoon, which is why, even though it may cost you money, you should only run current versions of the applications on your systems.

Information for this post came from Network World.

by