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

91–100 of 121 posts

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

#91

Post by dane-pgp »

sametmax wrote: post #6
Someone1234 wrote: post #2

7-Zip needs to start a Go Fund Me or similar for a Code Signing certificate. They're like $69-89/year, which is expensive, but for such a popular piece of software it would be a nice safety net in case of site compromise. Too bad none of the big CAs have an Open Source/Charity program that would provide a Authenticode Certificate for use with that software.

That could be a nice use case for a blockchain.

I can picture this working, actually. Someone could put some smart contracts into the Ethereum blockchain, for example, one per piece of software, with the instruction that if the contract receives more than a certain threshold in total donations, a transaction is sent to a CA asking them to issue a code signing cert to the developer of the relevant piece of software (hardcoded into the smart contract).

The CA would have to be in on this, by having an Ethereum address to receive the crowd-funded amount at, and they would have to make contact with the developer and verify them using their normal methods, but there would be a strong financial incentive for them persuade the developer to accept their certificate. Perhaps if the developer declines, then the funds controlled by the smart contract can expire and be sent back to the unsuccessful crowd-funders.

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

#92

Post by [deleted] »

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.

[deleted]

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

#93

Post by pkkm »

landave wrote: post #64
pkkm wrote: post #61

Earlier quoted context omitted.

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.

"Unaffected" was probably the wrong word to use. What I meant is that one of the mitigations (making the executables position-independent) should prevent the bug from being exploitable for remote code execution on Debian.

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

#94

Post by eterm »

Someone1234 wrote: post #13
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.

> It doesn’t help all that much anyway, SmartScreen still catches your application and nags the user. Windows 10, in the default configuration, won't let you install unsigned applications at all. It might "nag" early downloaders when a certificate is present but you can override that (and the nagging stops eventually due to popularity). But more importantly, if the site were ever compromised, it makes it easier to sp…

When I was just installing it now (this post reminded me that I hadn't updated it recently) I was put off by the lack of publisher in the installer and went back to double-check it was the official version. It's really off-putting seeing "publisher: unknown" when installing and my immediate reaction was, "wait, did I install it from the legit site?".

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

#95

Post by dingo_bat »

icebraining wrote: post #48
dingo_bat wrote: post #29

Earlier quoted context omitted.

If you follow C++14 core guidelines, the defect described would not have occurred. The bug at its core is usage of unsanitized input data. You don't need to "mandate that every value be a valid instance of its type wherever it is theoretically accessible", however that may differ from simple sane C++14 paradigms. OPINION ALERT: Honestly guys get over rust, it does not offer a single advantage in real-life programming…

So I have to read a 21762 line document just to avoid shooting myself on the foot? There's a Rust advantage right there.

Who said anything about reading a document?

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

#96

Post by AnIdiotOnTheNet »

staticassertion wrote: post #53
landave wrote: post #15

Earlier quoted context omitted.

DEP was previously disabled because Igor used to compile 7-Zip with VC6, which doesn't support the /NXCOMPAT flag. I convinced him back in January to enable it for 7-Zip 18.01. Note, however, that 64-bit versions of Windows enforce DEP even if the /NXCOMPAT flag is missing. Since Windows 10, the 32-bit version does this as well. ASLR was primarily disabled because Igor wanted to strip the relocation from the binaries…

Why is this such an uphill battle?

Developer cares about efficiency. It seems strange in today's world of Electron apps and text editors that take up a GB of ram and have hundreds of ms of latency, but that's clearly where his priorities lie and I, for one, can respect that.

If people are so up in arms about the security problems of 7-Zip, they're free to fork it.

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

#97

Post by steveklabnik »

platinumrad wrote: post #89
steveklabnik wrote: post #81

Earlier quoted context omitted.

Why is wondering “could another tool have solved this problem” come across as “hopelessly naïve?” It didn’t say Rust was the first. It also acknowledged that there’s great reasons it’s currently not used here.

Memes about programming languages (and programming language communities) die hard so it's probably a good idea to avoid reinforcing them when possible. I read this comment as a sort of implicit variant of "RIIR". Judging by the downvotes, I think others did the same. Rust probably doesn't even deserve the "RIIR" meme as 1) "RIIR" seems to happen way more often on HN/similar than on mailing lists or bug trackers and 2…

Thanks, that makes sense. I’m very interested in these kinds of perceptions, so I appreciate you taking the time.

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

#98

Post by netheril96 »

olfactory wrote: post #60

Why does anyone use 7-Zip? Does it have any advantages over the more widely used alternatives (tarball and zip)?

For me, it is support for unicode filenames.

There are extensions for tarball and zip file formats that handles the problem, but not many software supports these extensions, whereas every software supporting 7z handles unicode filenames correctly.

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

#99

Post by therealmarv »

pkkm wrote: post #93
landave wrote: post #64

Earlier quoted context omitted.

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.

"Unaffected" was probably the wrong word to use. What I meant is that one of the mitigations (making the executables position-independent) should prevent the bug from being exploitable for remote code execution on Debian.

thanks for the inside information about p7zip! That's really good to know!

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

#100

Post by icebraining »

dingo_bat wrote: post #95
icebraining wrote: post #48

Earlier quoted context omitted.

So I have to read a 21762 line document just to avoid shooting myself on the foot? There's a Rust advantage right there.

Who said anything about reading a document?

The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
Post reply on HN