Multiple 7-Zip Vulnerabilities Discovered(blog.talosintel.com)
blog.talosintel.com
Multiple 7-Zip Vulnerabilities Discovered
http://blog.talosintel.com/2016/05/multiple-7-zip-vulnerabilities.html
7 comments
7-zips track record of lack of vulnerabilities [1] would imply something entirely different to me. Only 2 CVEs ( and now this ) in a heck of a long time. 7z being used in quite a variety of places it seems like a lucrative attack vector, so I would expect that ample amount of fuzzing and other techniques has gone into trying to break it over the years. Which obviously doesn't mean, as these findings highlight, that it would be in any way infallible either. But to say they don't take security seriously sounds little unfair to me.
[1] https://www.cvedetails.com/vulnerability-list/vendor_id-9220...
[1] https://www.cvedetails.com/vulnerability-list/vendor_id-9220...
Just because you don't see a CVE doesn't mean there aren't major flaws. It just means the researcher didn't want to bother with getting a CVE.
Yes, the number of reported vulnerabilities isn't a good metric to judge the security of a project. It often means that few people bothered to look, and that when developers fixed a bug they didn't try to find out whether it was exploitable.
The latter is supported by the fact that changelog entries don't discriminate between security bugs and normal bugs, and by the fact that no vulnerability was ever reported by the developers themselves.
More worryingly, in all instances where a vulnerability was reported, the CVE vulnerability was filed specifically because the reporters were security researchers. This means that when a normal user reported a crash bug, no vulnerability was EVER filed. How likely do you think it is that none of those crashes could possibly be turned into an exploit? There are 95 instances of "Some bugs were fixed" in the changelog.
The latter is supported by the fact that changelog entries don't discriminate between security bugs and normal bugs, and by the fact that no vulnerability was ever reported by the developers themselves.
More worryingly, in all instances where a vulnerability was reported, the CVE vulnerability was filed specifically because the reporters were security researchers. This means that when a normal user reported a crash bug, no vulnerability was EVER filed. How likely do you think it is that none of those crashes could possibly be turned into an exploit? There are 95 instances of "Some bugs were fixed" in the changelog.
Suppose researchers looking at 7-zip were lazier getting their CVEs than those looking at Winrar, Winzip, Info-zip, zlib, bzip2, and other commonly used compression packages. ;-)
https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... https://www.cvedetails.com/vulnerability-list/vendor_id-816/... https://www.cvedetails.com/vulnerability-list/vendor_id-1198...
https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... https://www.cvedetails.com/vulnerability-list/vendor_id-816/... https://www.cvedetails.com/vulnerability-list/vendor_id-1198...
You can be appalled, but it's not like anyone's paying them for the work that they do.
If you want to help them, I'm sure you could contribute some additions to their build process or something that would help them tighten up security. But I think it's funny that you're so shocked that a popular free software project isn't perfect.
Be the change you want to see.
PS: who cares if the devs are using unsigned software downloaded over HTTP? I care about using signed software (and then I suppose the transport doesn't really matter), but that's totally unrelated to what the devs do on their own computers.
If you want to help them, I'm sure you could contribute some additions to their build process or something that would help them tighten up security. But I think it's funny that you're so shocked that a popular free software project isn't perfect.
Be the change you want to see.
PS: who cares if the devs are using unsigned software downloaded over HTTP? I care about using signed software (and then I suppose the transport doesn't really matter), but that's totally unrelated to what the devs do on their own computers.
Every time an open source project is criticised, you get people saying "why are you criticising, you should do the work" - to the point that this seems to be a mechanism to shutdown any and all criticism of any open source project via special pleading.
One can be very grateful for the work done on an open source project, and recognise that I have no right whatsoever to expect them to hop to it, but I am always free to criticise their work whether it is free or not. Just because a project is open source doesn't mean nobody can utter a bad word about it.
One can be very grateful for the work done on an open source project, and recognise that I have no right whatsoever to expect them to hop to it, but I am always free to criticise their work whether it is free or not. Just because a project is open source doesn't mean nobody can utter a bad word about it.
Thank you. To be clear, I don't mean that as a criticism of the developers, who as the parent points out do very useful work and do it for free. But I feel that it's important to have an objective look at the current shortcomings in the state of 7-zip security, both in order to understand what needs to be done to fix it, and in order to warn current users until those issues are fixed.
7-zip is a widely popular basic utility, like a web browser. A flaw in 7-zip is very serious, because as I pointed out elsewhere simply opening a .zip file will allow an attacker to exploit it. And while there is a strong security culture among web browser developers, 7-zip doesn't seem to have that culture (yet).
There is certainly a massive budget and manpower difference, but a lack of mention of security fixes in the changelog and a lack of hashes isn't a manpower issue, it's a culture issue.
As a side note, compromise of a developer's machine is a big deal in my opinion: it could be easy for a criminal entity to slip in a tiny change in a large patch that introduces a vulnerability; and depending on how builds are performed, a criminal could patch the final .exe with no visible change to the source code. These are tailored attacks, but for a very widely distributed program it would easily be worth the criminal's time.
7-zip is a widely popular basic utility, like a web browser. A flaw in 7-zip is very serious, because as I pointed out elsewhere simply opening a .zip file will allow an attacker to exploit it. And while there is a strong security culture among web browser developers, 7-zip doesn't seem to have that culture (yet).
There is certainly a massive budget and manpower difference, but a lack of mention of security fixes in the changelog and a lack of hashes isn't a manpower issue, it's a culture issue.
As a side note, compromise of a developer's machine is a big deal in my opinion: it could be easy for a criminal entity to slip in a tiny change in a large patch that introduces a vulnerability; and depending on how builds are performed, a criminal could patch the final .exe with no visible change to the source code. These are tailored attacks, but for a very widely distributed program it would easily be worth the criminal's time.
I'm glad you care so much, but I don't think you can fix a culture issue by explaining it away. The best way to set a culture where there hasn't been one before, is to lead by example.
Re: side note; the vulnerability described in the well-known Ken Thompson paper has been exploited just once in the wild. It's cool, but you could say the same thing about trusting Windows or proprietary drivers or hardware.
Re: side note; the vulnerability described in the well-known Ken Thompson paper has been exploited just once in the wild. It's cool, but you could say the same thing about trusting Windows or proprietary drivers or hardware.
I counter the Thompson claim as vastly overstated risk when I see it here. I hadn't even heard that it was ever done before. Do you have a link or the project/time? I try to track these things.
https://web.archive.org/web/20100305234633/http://www.h-onli...
Took some digging, but there it is.
Took some digging, but there it is.
Thanks for digging. I'll be damned! Somebody did pull it off. On my old, favorite platform as well!? So, one time on record.
Still supports my claim that reproducible builds and Thompson are mainstream buzzwords where our real concern per Orange Book days should be: coding defects in compiler source; effects of optimizations; malicious developers; trusted distribution of source; bootstrapping first, verified, local compiler. That's basically a human and machine verified compiler with simple code and signed zip's. Knocks out Thompson attack as side effect and negates reptoducible build need except for debugging.
Still supports my claim that reproducible builds and Thompson are mainstream buzzwords where our real concern per Orange Book days should be: coding defects in compiler source; effects of optimizations; malicious developers; trusted distribution of source; bootstrapping first, verified, local compiler. That's basically a human and machine verified compiler with simple code and signed zip's. Knocks out Thompson attack as side effect and negates reptoducible build need except for debugging.
I'm not talking about a "trusting trust" attack, which is difficult to pull off and requires special compiler knowledge because it needs to survive bootstrapping.
Here the attacker just needs to patch a binary once and he already has complete control over the machine, so he has an infinite number of options: from simply manually replacing the binary file before it's uploaded to the website, to replacing gcc with a script that patches the source code before calling the original gcc.
Here the attacker just needs to patch a binary once and he already has complete control over the machine, so he has an infinite number of options: from simply manually replacing the binary file before it's uploaded to the website, to replacing gcc with a script that patches the source code before calling the original gcc.
It's not shutting down the criticism. Someone will always say that ("you can fix it blah blah blah") but you can just ignore it. Just don't expect anyone to put in extra hours fixing it to avoid that criticism because people who do open source work for fun in their spare time, and people who give a shit what random people they don't know say about them online are two entirely separate groups.
Anyone's within their right to criticize an open source project. I think being "appalled" is a tad illogical, though.
Similarly, does complaining about it on a public forum have any effect? In my book, code speaks louder than words; if you really want to see change, you know what to do.
Similarly, does complaining about it on a public forum have any effect? In my book, code speaks louder than words; if you really want to see change, you know what to do.
Being appalled seems right to me.
Under many circumstances, our actions come with a certain degree of responsibility. When we write code, we have the responsibility to be pretty open about security.
Under many circumstances, our actions come with a certain degree of responsibility. When we write code, we have the responsibility to be pretty open about security.
Where's the users' responsibility factor in to support the project financially or with code contributions? A gift given as is implies no responsibilities. A tool given for money should work as advertised. Yet, all this talk of responsibility appears on FOSS projects and is one way.
They have no responsibility to anyone. If you want responsibility, there's commercial offerings or you can sponsor 7-zip security for money.
They have no responsibility to anyone. If you want responsibility, there's commercial offerings or you can sponsor 7-zip security for money.
Our actions do come with a certain degree of responsibility. It is the user's responsibility, then, not to use software that is "without warranty" if they do not firmly trust it.
You can claim irresponsibility whenever you want, but it takes two to tango.
You can claim irresponsibility whenever you want, but it takes two to tango.
Not everyone has enough bandwidth in their lives to actively fix every broken free/open source project out there.
Rather than being seen as attacks on a project, these sorts of comments are often just highlighting some things that whoever is looking at that particular project might want to fix.
The "don't criticise unless you're prepared to fix it" attitude is very similar to the sort of "Don't bring me problems, just solutions" attitude that some managers have that results in a culture of people keeping quiet about stuff they've spotted but don't have either the time or ability to fix themselves.
Rather than being seen as attacks on a project, these sorts of comments are often just highlighting some things that whoever is looking at that particular project might want to fix.
The "don't criticise unless you're prepared to fix it" attitude is very similar to the sort of "Don't bring me problems, just solutions" attitude that some managers have that results in a culture of people keeping quiet about stuff they've spotted but don't have either the time or ability to fix themselves.
I made specific criticisms about the parent poster being "appalled". Those are the kinds of comments that programmers on open source projects don't read, because they start "I'm appalled at how irresponsible your project is", and no one wants to read something like that.
Rather than leaving comments about how astounded we are, we should come up with a solution (which I'll note wasn't even mentioned in the parent post). Maybe a build step to autoregen the Downloads page? Maybe an email to the developers that will ask nicely for them to note which bug fixes are for security and which ones aren't?
Omission of facts is sometimes a defense mechanism for people who are embarrassed. The parent post could have only made the developer's insecurity about security greater. I understand that we have to make criticisms about open source software, but maintaining an open source project can sometimes be totally thankless work. We should try our best to Be Nice to people who work for free, because otherwise they won't want to work at all.
Rather than leaving comments about how astounded we are, we should come up with a solution (which I'll note wasn't even mentioned in the parent post). Maybe a build step to autoregen the Downloads page? Maybe an email to the developers that will ask nicely for them to note which bug fixes are for security and which ones aren't?
Omission of facts is sometimes a defense mechanism for people who are embarrassed. The parent post could have only made the developer's insecurity about security greater. I understand that we have to make criticisms about open source software, but maintaining an open source project can sometimes be totally thankless work. We should try our best to Be Nice to people who work for free, because otherwise they won't want to work at all.
> PS: who cares if the devs are using unsigned software downloaded over HTTP? I care about using signed software (and then I suppose the transport doesn't really matter), but that's totally unrelated to what the devs do on their own computers.
This is definitely a vector that attackers can and do use. If the developer is infected, particularly by a virus that changes the compiler to emit infected code, this can by proxy infect the products they develop.
See e.g.:
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
This is definitely a vector that attackers can and do use. If the developer is infected, particularly by a virus that changes the compiler to emit infected code, this can by proxy infect the products they develop.
See e.g.:
https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
See the note on my other comment: https://news.ycombinator.com/item?id=11686671
[deleted]
There are plenty of ways of defeating authenticode sig.
They should have hashes though.
They should have hashes though.
Can you give me pointers about authenticode flaws? After a quick search the two issues I found were with MD5 collisions (solution: the signer should never emit MD5 certificates) and certificate padding (solution: the user should set a registry key to enable verification of padding; search for "EnableCertPaddingCheck").
Here's a good pres:
https://recon.cx/2012/schedule/attachments/54_Signed_executa...
Their conclusion is simply that "the major part has been fixed" in MS12-024, and that you should be careful if you write a self-extracting installer. No big deal.
I have a bunch of samples right now that fake signatures.
Here's one example: https://virustotal.com/en/file/fe8fa4daa404ebb3bd6df4c20650a...
All of them are self-extracting installers (happen to be 7zip/Nullsoft). That successfully fake sigs. Nullsoft is the most popular packer/extractor out there.
Sure, there are ways of creating an installer with authenticode that cannot be faked, but much easier to just hash it and not worry about the terrible tech that is authenticode.
Edit: That's a fake Firefox installer with authenticode that checks out according to the spec. As you can see, this is not some weird edge case.
Here's one example: https://virustotal.com/en/file/fe8fa4daa404ebb3bd6df4c20650a...
All of them are self-extracting installers (happen to be 7zip/Nullsoft). That successfully fake sigs. Nullsoft is the most popular packer/extractor out there.
Sure, there are ways of creating an installer with authenticode that cannot be faked, but much easier to just hash it and not worry about the terrible tech that is authenticode.
Edit: That's a fake Firefox installer with authenticode that checks out according to the spec. As you can see, this is not some weird edge case.
The SHA256 of that file is exactly that of Firefox Setup Stub 35.0.1 (Win32), so of course Authenticode checks out.
I'm not 100% sure why some people thought it was a malicious file, but the comments on Virustotal mention [1] which, for me, redirects to the legitimate [2] but a comment seems to link it with [3] which is a completely different file. Perhaps the redirection is randomized so people got confused?
[1] hxxp://files.dodo-number-1.pw/p/MCLkP8Dzc3nUWJrG9fwGLA,1442015273/zte%20mf631%20firmware%20downlo_10924_i57945825_il345.exe (replace hxxp with http)
[2] https://download-installer.cdn.mozilla.net/pub/firefox/relea...
[3] https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6...
I'm not 100% sure why some people thought it was a malicious file, but the comments on Virustotal mention [1] which, for me, redirects to the legitimate [2] but a comment seems to link it with [3] which is a completely different file. Perhaps the redirection is randomized so people got confused?
[1] hxxp://files.dodo-number-1.pw/p/MCLkP8Dzc3nUWJrG9fwGLA,1442015273/zte%20mf631%20firmware%20downlo_10924_i57945825_il345.exe (replace hxxp with http)
[2] https://download-installer.cdn.mozilla.net/pub/firefox/relea...
[3] https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6...
Now this is a case for sandboxing. A decompressor has one input file and one output directory. It should not have the power to change any state outside those files.
A key point here is that not all code needs to be secure. Some code just needs to be kept in a box.
A key point here is that not all code needs to be secure. Some code just needs to be kept in a box.
I think OpenBSD's `pledge` syscall would be sufficient in this case. Calling
[0] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
pledge("stdio rpath wpath", {"path/to/input", "path/to/output"});
[0] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
Even if it's in a box, you need to pull the thing you want back out of the box. A malicious file could put a payload into the destination file.
Yes, by containing the payload and decompressing it.
The difference is that by not sandboxing it, that malicious file could also cause its payload to be executed in the permission scope of the decompressor.
The difference is that by not sandboxing it, that malicious file could also cause its payload to be executed in the permission scope of the decompressor.
That's pointless. Putting the malicious file in the archive would accomplish the same result.
We're at the point where tools can automatically transform code for safety with OK penalties and some MAC implementations have about no penalties. Yet, still no use on the exact types of tools they're easiest to apply to. (Shakes head.)
Same with transcoders
The discovered vulnerabilities are in the 7-Zip application's UDF and HFS+ filesystem image support.
I didn't even realize 7-Zip could open those.
7-Zip is the VLC of file containers.
Too bad it doesn't support unpacking .tar.gz files in a single step like their competition (WinZip) does.
It is my default whenever I'm on Windows. Everyone loves to close the "trial" window on software when there's usually a better open source alternative. The hidden gem in 7-Zip is you can set file association, it's just not enabled by default which makes it seem more complicated to newcomers than it really is.
Not really sure why you would need regular releases for handing zip files, though.
Windows handles zip files horribly.
The time to extract a 100MB zip in windows explorer is 4-6minutes (if not more). Compare this to ~30seconds in 7zip.
The time to extract a 100MB zip in windows explorer is 4-6minutes (if not more). Compare this to ~30seconds in 7zip.
Windows ignores the partition you're unzipping to and writes to the c drive, then does a very slow, tedious move to the destination partition. It's obvious it should use the destination partition in the first place.
[deleted]
PeaZip is like a friendly version of 7zip, and uses the 7zip code. 7zip is not very well maintained, whereas PeaZip has regular releases.
> 7zip is not very well maintained, whereas PeaZip has regular releases.
16.00 2016-05-10
15.14 2015-12-31
15.12 2015-11-19
15.11 beta 2015-11-14
15.10 beta 2015-11-01
15.09 beta 2015-10-16
15.08 beta 2015-10-01
15.07 beta 2015-09-17
...
How is that not regular?
16.00 2016-05-10
15.14 2015-12-31
15.12 2015-11-19
15.11 beta 2015-11-14
15.10 beta 2015-11-01
15.09 beta 2015-10-16
15.08 beta 2015-10-01
15.07 beta 2015-09-17
...
How is that not regular?
Perhaps lately. Prior to this past November, the stable release advertised on their site had been stuck on the same version for years, without even any point releases. And they use SourceForge for hosting.
The code quality may be excellent, but it just seemed to me that they were not too well organized, logistically, compared to other projects.
The code quality may be excellent, but it just seemed to me that they were not too well organized, logistically, compared to other projects.
Why would they need regular releases? This is not a web startup, it's an archive compression/decompression tool. It worked perfectly well 5 years ago.
I was wondering the same. Unless it involves a security being ignored for a year or more, I don't see much of an issue with a lack of updates. I rather a developer takes their time to write their code vs. speed coding and publishing new bugs left and right.
I find it unlikely that there would be no memory leaks needing patching, no important compiler updates, and no API-compatible dependency updates that should've been applied to the stable release.
The Linux Kernel, Firefox, and lots of projects have some sort of Long Term Service branch where simple uncontroversial improvements are added.
Modern best practices for releasing open source software are important, and a project that doesn't seem aware of any of them makes me concerned about their attention to detail.
The Linux Kernel, Firefox, and lots of projects have some sort of Long Term Service branch where simple uncontroversial improvements are added.
Modern best practices for releasing open source software are important, and a project that doesn't seem aware of any of them makes me concerned about their attention to detail.
The version they consider "stable" is rarely updated. That just means they have a very high standard for when it's considered stable.
If you look through the changelog you'll see that the largest gaps between any releases was from 9.25 alpha (2011-09-16) to 9.30 alpha (2012-10-26).
If you look through the changelog you'll see that the largest gaps between any releases was from 9.25 alpha (2011-09-16) to 9.30 alpha (2012-10-26).
[deleted]
I'm a tad confused. Say I had 7-zip installed - how would I be vulnerable? Hacker Henry knows I use UDF or HFS+ filesystem, AND gets me to trust them and download their maliciously compressed file, AND I extract it with 7-zip, which is exploited by one of these vulnerabilities?
If Henry can do all that, why couldn't Henry just get me to trust them and download a more robust malicious file in the first place without worry to what type of filesystem and decompression software I use?
If Henry can do all that, why couldn't Henry just get me to trust them and download a more robust malicious file in the first place without worry to what type of filesystem and decompression software I use?
The vulnerability isn't to do with what file system you're running, it's to do with using 7-zip to view the contents of archives in those file formats. Which means if someone wanted to view ala DVD ".iso" which used the UDF specification, then they could be vulnerable if they use 7-zip.
I remember it used to be common place to open .iso files with WinRar back in the 90s. I wouldn't be surprised if a sizeable number of people now use 7-zip similarly
I remember it used to be common place to open .iso files with WinRar back in the 90s. I wouldn't be surprised if a sizeable number of people now use 7-zip similarly
I just did some testing and it's even worse than that: 7-zip completely ignores the file extension and snoops the file format based on the file contents only.
So simply opening a malicious ".zip" file on Windows could trigger the HFS+ vulnerability. Using 7-zip to open any file means you have a HUGE attack surface.
EDIT: One simple way to mitigate this issue would be to just throw a confirmation prompt if the file extension matches a known format but 7-zip is about to run a decoder for a different format.
So simply opening a malicious ".zip" file on Windows could trigger the HFS+ vulnerability. Using 7-zip to open any file means you have a HUGE attack surface.
EDIT: One simple way to mitigate this issue would be to just throw a confirmation prompt if the file extension matches a known format but 7-zip is about to run a decoder for a different format.
IIRC, 7-zip does tell you if the actual format is different. At least it does when I extract some DMGs; it tells me it's actually an HFS "file".
Not on Windows, at least. The properties dialog can tell you it uses HFS+ if you ask for it, but it's too late because the HFS+ code has already been executed.
I meant when right clicking the archive am choosing "Extract to..." or something using Explorer's context menu.
Interesting, it does display a warning in this case! But it doesn't interrupt extraction so if it's a malicious file the code will still execute.
What exactly do you mean by more robust malicious file? Like an executable? Because I'm relatively OK with extracting files from dubious sources, I'm not OK with running executables from dubious sources.
Yes, there are trust levels associated with running untrusted code, and processing untrusted data. It's possible (but often hard and annoying) to access some external/untrusted resources such as the internet and items on them without running untrusted code, it is not possible to do so without processing untrusted data (at a minimum it's going to traverse your network stack and display/disk drivers).
Many people put more trust in unzipping something than running untrusted code.
Archives are supposed to be read only.
Archives are supposed to be read only.
Because Henry is Hardcore.
I always found it strange that 7-zip appears to be developed by a single individual, despite being very popular.
I know the fact that this lone developer apparently resides in Russia has caused 7-zip to be outright banned in certain places.
I know the fact that this lone developer apparently resides in Russia has caused 7-zip to be outright banned in certain places.
> I know the fact that this lone developer apparently resides in Russia has caused 7-zip to be outright banned in certain places.
That's a particularly ignorant approach, especially considering the whole thing is open-source and auditable.
That's a particularly ignorant approach, especially considering the whole thing is open-source and auditable.
> ignorant
That's my tax dollars at work. :)
That's my tax dollars at work. :)
Darn 16.0 upgrade insisted on rebooting my Windows.
Should not be necessary in 2016
Should not be necessary in 2016
collective yawn
The changelog only says "Some bugs were fixed", with no mention that there are serious security flaws. The homepage doesn't mention any vulnerability.
The installer is not signed, downloads are over HTTP only, and there is no hash available neither on the homepage or on the forum announcement linked from the homepage (the latter is served over HTTPS so it would be a reasonable option); thankfully you can dig around Sourceforge downloads to find a SHA-1 automatically generated by Sourceforge. So I can personally verify the integrity of downloads, assuming Sourceforge can still be trusted, but 99% of users won't do this, and more worryingly it's a strong signal that the developers may not understand or value security very much: you have to wonder if maybe they're not themselves downloading unsigned software over HTTP all the time.