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

21–30 of 72 posts

Re: Multiple 7-Zip Vulnerabilities Discovered

#21

Post by paulfr »

lqdc13 wrote: post #20
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…

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

Re: Multiple 7-Zip Vulnerabilities Discovered

#22

Post by Splines »

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#23

Post by colejohnson66 »

paulfr wrote: post #17
laumars wrote: post #12

Earlier quoted context omitted.

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

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

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

Re: Multiple 7-Zip Vulnerabilities Discovered

#24

Post by striking »

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…

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#25

Post by nwah1 »

poizan42 wrote: post #18
nwah1 wrote: post #11

Earlier quoted context omitted.

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?

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#27

Post by valarauca1 »

arkitaip wrote: post #14
giancarlostoro wrote: post #9

Earlier quoted context omitted.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#28

Post by tekklloneer »

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.

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.

Re: Multiple 7-Zip Vulnerabilities Discovered

#29

Post by doomrobo »

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.

I think OpenBSD's `pledge` syscall would be sufficient in this case. Calling

    pledge("stdio rpath wpath", {"path/to/input", "path/to/output"});
would blacklist any subsequent syscall that are not in the stdio or rpath or wpath lists [0] or pertain to a file that is not the input or output.

[0] http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...

Re: Multiple 7-Zip Vulnerabilities Discovered

#30

Post by JetSetWilly »

striking wrote: post #24
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…

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

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.

Post reply on HN