Multiple 7-Zip Vulnerabilities Discovered

http://blog.talosintel.com/2016/05/multiple-7-zip-vulnerabilities.html

by adamnemecek • 10 years ago

122 68 10 years ago

blog.talosintel.com

hcs• 10 years ago

The discovered vulnerabilities are in the 7-Zip application's UDF and HFS+ filesystem image support.

striking8• 10 years ago

I didn't even realize 7-Zip could open those.

infogulch• 10 years ago

7-Zip is the VLC of file containers.

mamurphy• 10 years ago

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?

adamnemecek• 10 years ago

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.

kbenson• 10 years ago

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

lqdc134• 10 years ago

Many people put more trust in unzipping something than running untrusted code.

Archives are supposed to be read only.

excalibur• 10 years ago

Because Henry is Hardcore.

laumars• 10 years ago

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

paulfr10• 10 years ago

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.

Animats2• 10 years ago

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.

mentat• 10 years ago

Same with transcoders

Splines• 10 years ago

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.

tekklloneer• 10 years ago

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.

Animats2• 10 years ago

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

doomrobo• 10 years ago

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

nickpsecurity4• 10 years ago

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

paulfr10• 10 years 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.

lqdc134• 10 years ago

There are plenty of ways of defeating authenticode sig.

They should have hashes though.

paulfr10• 10 years 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").

striking8• 10 years 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• 10 years 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.

eslaught• 10 years ago

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

prof_hobart• 10 years ago

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.

realkitkat• 10 years 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...

danielweber• 10 years 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.

ck2• 10 years ago

Darn 16.0 upgrade insisted on rebooting my Windows.

Should not be necessary in 2016

wfsfw4w44• 10 years ago

Windows

abcd_f• 10 years ago

Explorer integration is a finicky business.

One huge tangle of dependencies, most of which concealed by COM abstractions. Even if you kill explorer.exe, something somewhere may end up holding a reference to your binary with a reboot being the only way around it.

cloudjacker• 10 years ago

collective yawn

dewyatt2• 10 years ago

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.

jszymborski• 10 years ago

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.

dewyatt2• 10 years ago

ignorant

That's my tax dollars at work. :)

Multiple 7-Zip Vulnerabilities Discovered

Related Stories