[paulfr]

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

[realkitkat]

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

[danielweber]

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.

[paulfr]

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.

[rexter]

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

[striking]

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.

[JetSetWilly]

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.

[paulfr]

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.

[striking]

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.

[nickpsecurity]

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.

[striking]

https://web.archive.org/web/20100305234633/http://www.h-onli...

Took some digging, but there it is.

[paulfr]

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.

[dave2000]

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.

[striking]

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.

[de47]

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.

[nickpsecurity]

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.

[striking]

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.

[prof_hobart]

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.

[striking]

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.

[eslaught]

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

[striking]

See the note on my other comment: https://news.ycombinator.com/item?id=11686671

[lqdc13]

There are plenty of ways of defeating authenticode sig.

They should have hashes though.

[paulfr]

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

[lqdc13]

Here's a good pres: https://recon.cx/2012/schedule/attachments/54_Signed_executa...

[paulfr]

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.

[lqdc13]

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.

[paulfr]

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