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

7-Zip: From Uninitialized Memory to Remote Code Execution

landave.io

Post reply on HN
Print view View original

61–70 of 121 posts

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#61

Post by pkkm »

landave wrote: post #22
therealmarv wrote: post #18

Great, p7zip is also affected according to an earlier article [1] and the last version 16.02 is from 2016 [2] This open source libraries are used everywhere :( [1]: https://landave.io/2018/01/7-zip-multiple-memory-corruptions... [2]: https://sourceforge.net/projects/p7zip/files/p7zip/

Note that the standard 'p7zip' package from Debian/Ubuntu doesn't support RAR. However, they have an additional package 'p7zip-full' or 'p7zip-rar' for RAR support. I didn't check explicitly, but I assume these are affected.

I checked the versions in buster (p7zip-full 16.02+dfsg-6, p7zip-rar 16.02-2) and they look unaffected to me. Turns out that the Debian maintainers patch upstream sources to include hardening flags, e.g. -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,relro. You can use hardening-check to check the binaries on your system.

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#62

Post by MereInterest »

superflyguy wrote: post #58
therealmarv wrote: post #11

My guess: Because 7zip is not a good auto update software (does it even warn if there is a new version?) this security bug is HUGE! Just give you an example: Many Germans think that http://www.7-zip.de/ is the official site and you still download 16.04 there.

I just checked and I was on v9 from 8 years ago on my work pc. Why bother fixing security bugs etc if you're not going to roll them out? With other Windows software I get told about updates when I load them (winscp, Virtualbox) or they check and update themselves (Firefox).

Because there are multiple conflicting priorities here. On the one hand, it is good to keep software updated, and therefore software should check for updates. On the other hand, software should restrict itself to solving one problem domain. Interacting with the internet is something wholly distinct from decompressing files, and so the software should not branch off into a new domain. Choosing between these priorities is not necessarily straightforward.

I could also argue that automatic updates are themselves a security hole. They are a way for new code to be downloaded and run, without notifying the user. As a result, it means that your security depends on the security of a machine not under your control. Not too much of a risk for Firefox, but imagine having a program that auto-updated from SourceForge during its experimental fling as a malware distributor.

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#63

Post by dragontamer »

y4mi wrote: post #33
Tomte wrote: post #23

Earlier quoted context omitted.

Well, it says „official website“. If it isn‘t the author should send a C&D, this is really unfair.

Yeah, there is no question about it. This website clearly says that it's the legit source for 7zip. There is even a red box on the right side of the page. This needs to be taken down if this is not an official source. The left side has a navigation to different translations of the page. All but the English version link to the German page as well. I'm guessing it was once part of the build pipeline but has since been…

Or you know, the author of 7-zip could pay for a digital certificate and sign the executable. Fake websites and "Trojans" are a known problem, with a known solution.

Unfortunately, 7-zip barely has any security involved. No digital signatures, no ASLR, no NX bit, no stack canaries, no nothing.

Hopefully these security concerns wake up Ivor. Its not the 90s anymore: developers have to participate to get a proper security posture. That's why Windows tried so hard to get everyone to use sandboxed Win10 Apps / Metro Sandbox by default, because these problems require the developers to care about security.

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#64

Post by landave »

pkkm wrote: post #61
landave wrote: post #22

Earlier quoted context omitted.

Note that the standard 'p7zip' package from Debian/Ubuntu doesn't support RAR. However, they have an additional package 'p7zip-full' or 'p7zip-rar' for RAR support. I didn't check explicitly, but I assume these are affected.

I checked the versions in buster (p7zip-full 16.02+dfsg-6, p7zip-rar 16.02-2) and they look unaffected to me. Turns out that the Debian maintainers patch upstream sources to include hardening flags, e.g. -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,relro. You can use hardening-check to check the binaries on your system.

Okay, so these packages come with more mitigations than 7-Zip on Windows. However, looking at the source code, I am pretty sure they are affected by the same bug.

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#65

Post by drzaiusapelord »

jessaustin wrote: post #8
landave wrote: post #7

There were some misunderstandings that I want to clear up (maybe I will add them in an update to the blog post): 1. Some people mentioned that this would "only affect RAR files" and it would be safe to extract 7z files with 7-Zip prior to version 18.05. This is wrong, because 7-Zip detects the file type from the magic numbers at the beginning of the file. So the exploit can be renamed to 'exploit.7z' and it works jus…

This includes various anti-virus software. It's fascinating that this category of equipment, which searches for viruses by running untrusted code , is still regularly installed in all corners of valuable networks.

What AVs use this? I keep hearing horrible things about AVs but little proof. I know Tavis from Google finds bugs and AV in rare cases can reduce security, but that's a far cry from them embedding FOSS projects to save time. For AV companies writing a rar parser is a single-day activity, its hard to believe they need this app.

The few places I've seen 7z used is in installers where the input is known (installer archive in 7z format) and I'm assuming signed in many cases so you can't feed it random inputs. I find it hard to believe Sophos and Symantec and Trend are copying and pasting 7zip.dll into their apps.

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#66

Post by Boulth »

wyday wrote: post #12
fuzzy2 wrote: post #9

Earlier quoted context omitted.

IIRC 7-Zip has explicitly decided not go get signed. It doesn’t help all that much anyway, SmartScreen still catches your application and nags the user. Unfortunately, I cannot seem to find any reference, so I might remember it wrong or it wasn’t about 7-Zip or whatever. The thing with SmartScreen is (unfortunately) still true.

EV Code signing certs get you immediate trust with Smart Screen. Recently discussed over on the bootstrapped forum: http://discuss.bootstrapped.fm/t/code-signing-certificate-re... Regular, non-EV code-signing certs, aren't as useful as they were when Vista / Windows 7 were the main Windows OSes.

I wonder what do you mean by "not useful"? They just have to participate in the reputation system, but that's an issue only when the certificate is young.

Here's an excerpt from MSDN:

> Detractors may claim that SmartScreen is “forcing” developers to spend money on certificates. It should be stressed that EV code signing certificates are not required to build or maintain reputation with SmartScreen. Files signed with standard code signing certificates and even unsigned files continue to build reputation as they have since Application Reputation was introduced in IE9 last year. However, the presence of an EV code signing certificate is a strong indicator that the file was signed by an entity that has passed a rigorous validation process and was signed with hardware which allows our systems to establish reputation for that entity more quickly than unsigned or non-EV code signed programs.

Source: https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-sma...

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#68

Post by [deleted] »

RaleyField wrote: post #42
blibble wrote: post #28

Earlier quoted context omitted.

> You're just asking for too much. I know it's not you saying this, but it's very strange given almost all files 7-zip will ever see are untrusted files downloaded from the internet I'd rather have it be 1% slower than be compromised!

For virtually everybody even 500% slower would be acceptable. 1% is 10 second, one-time cost, which is objectively a fool's bargain.

[deleted]

Re: 7-Zip: From Uninitialized Memory to Remote Code Execution

#70

Post by platinumrad »

mraison wrote: post #17

Nowadays when that sort of bug is discovered, the question that naturally comes to my mind is "would that have happened if the software were implemented in (safe) Rust"? In that case it looks like the answer is no. Of course 7-zip is much older than Rust so that's just a thought experiment.

Comments like this hurt the adoption of Rust by making the community seem hopelessly naive. It's just how people make the Go community look bad by acting like Go invented CSP.

Rust is a (very?) good language that I hope will see more adoption but it is not the first memory safe language. Garbage collected languages are perfectly appropriate in many situations. Ada is almost 40 years old.

Post reply on HN