Compression tool 7-Zip pwned, pain flows to top security, software tools Some of the world's biggest security and software vendors will be rushing to patch holes in implementations of the popular 7-zip compression tool to stop attackers gaining full control of customer machines. Cisco security researcher Marcin Noga found and reported the holes to the maintainers of the open source 7-Zip platform …
7-zip ignores the file name when parsing it, so any .zip or .rar could potentially mask a UDF or HFS exploit. Obviously anything you have up to now wouldn't be a problem, you just have to carefully examine or decline everything new (or use another unzipper) until you upgrade to 16.x.
Ah, those were the days, being especially careful with arrays. That reminds me of a joke our concertmaster (ZM) (way back when) told in explaining the phrasing of the beginning of Beethoven's 1st Symphony, [which could well apply to some programmers(!)].
A violinist is asking Toscanini for a raise (to tune of Beethoven's 1st, 4th movement);
T: What you say?
V: I want a raise.
T: What was that you said?
V: I - uh wanted a raise.
T: That's what I thou-ought you said...
You are already making too much money...
.
.
And the freshly-minted programmer asks his boss,
PHBoss: What you say?
Progr: I want arrays.
PHB: What was that you said?
P: I - uh wanted arrays.
PHB: That's what I thou-ought you said...
You are already using too much data...
[looks around for a Beethoven bust like Schroeder used to have...]
"Forty years ago bounds checking was something done automatically at runtime - the underlying causes of this practice falling out of fashion still seem be around today"
This became available a few years beforehand, and in 1987 I used it as a matter of routine for production programs:
COBOL /CHECK=(BOUNDS, PERFORM) progname
I assume from the article that the main problem is 7-Zip code integrated into other products?
Which don't require a stand alone install of 7-Zip to work?
So the solution is to make sure your anti-virus/malware is up to date?
Also update any stand alone copies of 7-Zip?
Or what?
The problem is that an attacker can craft a malicious 7zip archive which will make the 7zip process (either the stand-alone version or integrated as library code in some other product) execute whatever code the attacker wants, with the same privileges as the 7zip process.
This is somewhat dangerous for the stand-alone 7zip: somebody can mail you a .7z file and ask you to decompress it. If you do, you get p0wned.
However, more dangerous is other products receiving and decompressing .7z files automatically. For example, a virus scanner which might want to open the .7z archive to check the contents for malware!
"- Some bugs were fixed."
that's still A LOT more content in a changelog than the Dropbox release notes, which just show this:
4.3.22[Testing]5/9/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes. Read all about our new versioning scheme (aka why is this version 4.3.22?) at [blablabla..url removed]
3.20.1[Stable]5/9/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.19.35[Testing]5/5/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.19.34[Testing]4/27/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.19.33[Testing]4/22/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.19.32[Testing]4/21/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.19.31[Testing]4/20/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.18.1[Stable]4/8/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.17.32[Testing]3/29/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
3.17.31[Testing]3/22/2016
Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes.
Yes, of course. The changelog should detail all exploits fixed, so that baddies that weren't aware of the problem can exploit exactly the right versions. Good idea.
While that concept is valid in some respects, it's completely the opposite of good practise, which is to explicitly list and link to the CVE so users/admins/etc can gain the knowledge needed to protect themselves.
The assumption is that "the baddies" already know of the problem - or will soon via their own means. So the information in the changelog isn't expected to help all but the most clueless/inept of the baddies.
Weirdly, even though the two CVE's are listed in the Talos info page, they're not in the Mitre CVE database. Release timing problem?
How many of the products using it are based off version 9.20?
Well further to my previous post, the version of Trend Micro Client Server Security Agent on one Win7 PC is v4.57 - which predates UDF support. I've not investigated the IBM Thinkpad as I know IBM/Lenovo use 7zip in their ThinkVantage software for XP and Win7 - However, I suspect this is also a pre v4.59 beta release given the release dates on many of the utilities.
I suspect that once you start to look at things, if all you are doing is performing command line extraction of files from basic zip archives, why do you actually need the latest version of 7zip? Although in saying that I've updated the version I've got on my useful tools USB stick to the latest.
Mine didn't complain. Just installed over the top of the previous version with no restart required.
I suspect the key here may be if you are using one of the AV products that uses it. That'll be running in the background and the 7-zip installer won't have the necessary privilege to stop and restart it. Hence the necessity for a full restart.
Half-full glass: The 7zip library is a DLL so all those apps don't need updating separately (even if vendor still exists, cares enough, you know it needs manual update)
Half-empty glass: The library is a DLL so thanks to inadvertent API break some of your apps now screw-up in inscrutable ways (unless all affected versions get bug fix release)
On *nix systems it should be easy to write a one-liner to search for all executables and use ldd to check what dynamically loaded libraries it depends on. I assume there's something similar to ldd on Windows. Problem with that is, I guess that people who develop Windows programs tend more towards using static linking. Maybe EXE explorer [link] can help there. The stackoverflow thread here suggests using the DUMPBIN program that comes with Visual Studio.
On *nix systems it should be easy to write a one-liner to search for all executables and use ldd to check what dynamically loaded libraries it depends on. I assume there's something similar to ldd on Windows.
On either platform, that only identifies "implicit" dependencies - the ones loaded automatically by the loader at runtime. It doesn't help with dependencies that are loaded by application code using explicit calls to the loader routines (e.g. dlopen on UNIX/Linux, LoadLibrary on Windows).
And you really need to build a graph of dependencies, because an executable may depend on library A, which in turn depends on library B. The SVR4 linking model supports .dynamic sections in shared objects, and the Windows PE format has similar capability.
And then there's static linking, as you noted.
So while it may be worth doing, it's certainly not guaranteed to find all uses of the suspect code.
Yes!
UDF support was first included in v4.59 beta (released in 2008) and hence would have been included in formal releases 4.63 and later, specifically the long-term stable release and hence widely used v9.20 (released in 2010).
However, what is going to be problemmatic, isn't upgrading the standalone installed version (ie. the version in folder c:\program files\7-zip\ ), but all those versions that vendors have bundled with their applications, for example:
C:\Program Files (x86)\Trend Micro\Client Server Security Agent\7z.*
1. Was just being more of smart ass than anything. They wouldn't at least where I work and a company that did probably wouldn't keep me as employee for very long (if they are doing that they are probably doing a whole bunch of other mickey mouse crap as well).
2. Who said anything about large files? I tend to zip (not xz, for portability with non nerds) every attachment to avoid the filters regardless of size.
Why on earth are you using e-mail for sending large files. You should invest in a computer network.
You should meet some computer users. I spent years trying to break my co-workers of the habit of sending multi-megabyte files by email to dozens of recipients. Eventually I gave up; I wasn't having any success at all.
We have plenty of alternatives available on the internal network for distributing files, both fairly good (FTP, various HTTP servers) and bad (Sharepoint, SMB). They're all better than email. But email is Right There, so that's what 95% of the employees use.
Why on earth are you using e-mail for sending large files. You should invest in a computer network.
You should meet some computer users.
"... I spent years trying to break my co-workers of the habit of sending multi-megabyte files by email to dozens of recipients. ... But email is Right There, so that's what 95% of the employees use."
Totally agree, I found very few normal users used the alternative methods, complaining whenever their attachment broke the size limit. Rather than give up, I looked for KISS solutions.
That's why in several clients I invested in managed file transfer solutions that included Outlook integration. With these the user used Outlook as normal, only the MFT solution automatically handled the very large attachment, uploading it to a server and replacing the email attachment with a URL.
The only complaint I've received has been from a user who clicked on such a PDF attachment and wondered why after 20 minutes it had not opened and was still down loading - not realising that a print ready version of a 5m x 2m banner is a very large file...
could someone explain how this works?
does malicious code have to be in the archive file?
sounds like you still have to be tricked into clicking on something stupid
If malware bytes zip their stuff up in 7zip format , without viruses , and I unzip it , whats the problem?
There are lots of programs that will take a manual update so become vulnerable.
It's bad practice to leave a vulnerability on the basis "it probably won't happen to me" because you can't predict when another future vulnerability will work with this one to make an exploit.
As we've seen, air gap machines are just as vulnerable as internet connected machines when it comes to malware and a determined miscreant.
sounds like you still have to be tricked into clicking on something stupid
As others have noted, it's quite common to have programs that automatically process compressed archives, and many of them use 7-zip code to do so.
But even if that weren't the case, "tricked into clicking" is not a sufficient bar. Even security-conscious users aren't good at perfect vigilance, and expecting ordinary users to avoid malware is rank foolishness.
Recent studies suggest spear phishing has around a 90% success rate if at least ten people in an organization are targeted. We've had decades of administrators complaining about people doing "something stupid", and it hasn't helped at all.
It's hard to tell. There is some discussion about this on the p7zip forum:
https://sourceforge.net/p/p7zip/discussion/383043/thread/9d0fb86b/?limit=25#3933
No indication of a new release or similar though, at the time of writing this.
Seems like p7zip isn't affected:
https://sourceforge.net/p/p7zip/discussion/383043/thread/9d0fb86b/#3220
That'll be good news for some. :)
While it's not the same as an immediate root level exploit, it's still pretty bad. Any kind of tooling which can be compromised just by opening a .zip file (or similar) still has a lot they can do from a user account.
It also sounds capable enough to be very effective when paired with a (local-only) root privilege escalation vulnerability.
I fail to see how this is a big deal? 7zip has no service and unless someone already has local access to the computer remotely they won't be able to run anything against the 7zip process. If they already have execute access then a 7zip vulnerability like this is not going to get them any further. 7zip patch it right away anyway. Just show the value of open source, not only is it free, but it is continuously audited and updated. Well not always, but a lot of the more popular projects are.
I fail to see how this is a big deal?
And that makes you part of the problem.
Vulnerabilities in non-privileged applications that require user interaction are still routinely exploited and used as part of multi-step penetration processes. Non-interactive remote-code execution and privilege elevation are not the only threats to system integrity.
So let's repeat the salient points:
- Many programs do process archive files without user intervention.
- Vulnerabilities that require user interaction are routinely exploited anyway.
- Successful execution of hostile code means the attacker owns that account. That's worse if it's a privileged account, but it's bad enough when it's an ordinary one.
- Attackers have used many, many approaches to pivot and elevate. Sometimes it's a simple as installing a key logger, then mucking up the machine, and waiting for the user to hand it over to an administrator for fixing; nine times out of ten, said admin will start by entering an admin password. Game over.
**** I've got some passwords that need changing. What you say is totally obvious, and yet I'd not thought of it. I've no cause to believe my passwords compromised and I've never found a keylogger on any system I've used other than the ones I put there myself to save me from losing my work, and yet despite the computers being scanned I don't know that my passwords weren't captured. (One hits a shortcut before entering a password to temporarily stop the logging) I'd have changed the passwords before, but the malware I removed didn't steal passwords according to what I found out about it, but then, do I know the description was correct and complete? Malware detection is never 100%.
Without nuking the hard drive how does one clean malware from a machine without entering an admin password? If one already had sufficient security software in place that might be used, but then that software should have detected and prevented the infection in the first place?
In answer to my own question one might pull the hard drive and scan it from outside the computer, but that does make things more complicated. Does anyone have a better option? Are those wonky on screen random letter keyboards any good?
I salute you Michael Wojcik.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
