4 ms·

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

by paulfr 10y ago

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.

lqdc13 10y ago
There are plenty of ways of defeating authenticode sig. They should have hashes though.
- paulfr 10y ago
  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 10y ago
    Here's a good pres: https://recon.cx/2012/schedule/attachments/54_Signed_executables.pps https://recon.cx/2012/schedule/attachments/54_Signed_executa...
    - paulfr 10y ago
      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 10y ago
        I have a bunch of samples right now that fake signatures. Here's one example: https://virustotal.com/en/file/fe8fa4daa404ebb3bd6df4c20650a1c94ee686d0fe624aa4cda3fe7d1282ce32/analysis/ 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 10y ago
        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/releases/35.0.1/win32/en-US/Firefox%20Setup%20Stub%2035.0.1.exe https://download-installer.cdn.mozilla.net/pub/firefox/relea... [3] https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6c6fe2d83d830ac75f384cff0dbef279a919b956/analysis/1442014883/ https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6...
striking 10y ago
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 10y ago
  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 10y ago
    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.
realkitkat 10y ago
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/7-zip.html https://www.cvedetails.com/vulnerability-list/vendor_id-9220...
- danielweber 10y ago
  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 10y ago
    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 10y ago
    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/Winzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-787/Winzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1670/GNU-Gzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... https://www.cvedetails.com/vulnerability-list/vendor_id-816/Info-zip.html https://www.cvedetails.com/vulnerability-list/vendor_id-816/... https://www.cvedetails.com/vulnerability-list/vendor_id-1198/product_id-2068/Bzip-Bzip2.html https://www.cvedetails.com/vulnerability-list/vendor_id-1198...
deleted 10y ago
[deleted]

by paulfr 10y ago

lqdc13 10y ago

There are plenty of ways of defeating authenticode sig. They should have hashes though.

paulfr 10y ago
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 10y ago
  Here's a good pres: https://recon.cx/2012/schedule/attachments/54_Signed_executables.pps https://recon.cx/2012/schedule/attachments/54_Signed_executa...
  - paulfr 10y ago
    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 10y ago
      I have a bunch of samples right now that fake signatures. Here's one example: https://virustotal.com/en/file/fe8fa4daa404ebb3bd6df4c20650a1c94ee686d0fe624aa4cda3fe7d1282ce32/analysis/ 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 10y ago
        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/releases/35.0.1/win32/en-US/Firefox%20Setup%20Stub%2035.0.1.exe https://download-installer.cdn.mozilla.net/pub/firefox/relea... [3] https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6c6fe2d83d830ac75f384cff0dbef279a919b956/analysis/1442014883/ https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6...

striking 10y ago

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 10y ago
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 10y ago
  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.

realkitkat 10y ago

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/7-zip.html https://www.cvedetails.com/vulnerability-list/vendor_id-9220...

danielweber 10y ago
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 10y ago
  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 10y ago
  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/Winzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-787/Winzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-787/... https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1670/GNU-Gzip.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... https://www.cvedetails.com/vulnerability-list/vendor_id-816/Info-zip.html https://www.cvedetails.com/vulnerability-list/vendor_id-816/... https://www.cvedetails.com/vulnerability-list/vendor_id-1198/product_id-2068/Bzip-Bzip2.html https://www.cvedetails.com/vulnerability-list/vendor_id-1198...

deleted 10y ago

[deleted]