Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple 7-Zip Vulnerabilities Discovered

blog.talosintel.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Multiple 7-Zip Vulnerabilities Discovered

#51

Post by Animats »

Splines wrote: post #22
Animats wrote: post #13

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.

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.

That's pointless. Putting the malicious file in the archive would accomplish the same result.

Re: Multiple 7-Zip Vulnerabilities Discovered

#52

Post by nickpsecurity »

striking wrote: post #49
nickpsecurity wrote: post #44

Earlier quoted context omitted.

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.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#53

Post by danielweber »

realkitkat wrote: post #34
paulfr wrote: post #15

I am appalled at how unseriously 7-zip seems to take security. 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…

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 i…

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#54

Post by paulfr »

danielweber wrote: post #53
realkitkat wrote: post #34

Earlier quoted context omitted.

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 i…

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#56

Post by paulfr »

striking wrote: post #40
paulfr wrote: post #31

Earlier quoted context omitted.

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…

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.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#57

Post by colejohnson66 »

paulfr wrote: post #33
colejohnson66 wrote: post #23

Earlier quoted context omitted.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#58

Post by paulfr »

colejohnson66 wrote: post #57
paulfr wrote: post #33

Earlier quoted context omitted.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#59

Post by poizan42 »

nwah1 wrote: post #25
poizan42 wrote: post #18

Earlier quoted context omitted.

> 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?

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 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).

Re: Multiple 7-Zip Vulnerabilities Discovered

#60

Post by lqdc13 »

paulfr wrote: post #21
lqdc13 wrote: post #20

Earlier quoted context omitted.

There are plenty of ways of defeating authenticode sig. 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...
Post reply on HN