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

81–90 of 121 posts

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

#81

Post by steveklabnik »

platinumrad wrote: post #70
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.

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.

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

#82

Post by user5994461 »

RaleyField wrote: post #74
RaleyField wrote: post #42

Earlier quoted context omitted.

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

Why am I getting downvoted? I sincerely wonder what is so objectionable in my comment. Most uses of 7-zip are one-off events that last around a minute long. Most users aren't decompressing terabyte-range files. It makes no fracking difference to users if they have to wait 5 minutes or 1 minute. But it makes a difference if they receive 7z archive and get their bank account cleaned because the author prematurely optim…

Consider that it was misplaced to suggest a 500% performance drop. It's used to extract large archives, backups, videos, documents. Folks don't want it to take half an hour instead of a few minutes.

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

#85

Post by robocat »

landave wrote: post #27
leeter wrote: post #21

Earlier quoted context omitted.

If you can convince him to use Control Flow Guard, Stack Canaries, and HE-ALSR then you should be nominated for for whatever the security community has as an equivalent to a Nobel prize. If you can convince him to get rid of his custom garbage Stdlib replacements and use ISO C++ then you're a hero to maintainability (and would probably improve the performance because the stdlib has move support).

HE-ASLR I am discussing with him right now, and I think we will get this. But honestly, I don't think we will ever see a 7-Zip with /GS or CFG. Not only would this cost about 1% in binary size, it would cost an additional 1% in runtime performance loss. Additionally, it would require compiling 7-Zip with a modern compiler like VS2017. You're just asking for too much.

> Additionally, it would require compiling 7-Zip with a modern compiler like VS2017

Ahhh, but does say VS2017 produce a smaller executable file, or a faster executable?

I am pleased Igor cares about individual 1% improvements - they stack up to significant savings. However I agree for our work usage security is more important.

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

#86

Post by landave »

robocat wrote: post #85
landave wrote: post #27

Earlier quoted context omitted.

HE-ASLR I am discussing with him right now, and I think we will get this. But honestly, I don't think we will ever see a 7-Zip with /GS or CFG. Not only would this cost about 1% in binary size, it would cost an additional 1% in runtime performance loss. Additionally, it would require compiling 7-Zip with a modern compiler like VS2017. You're just asking for too much.

> Additionally, it would require compiling 7-Zip with a modern compiler like VS2017 Ahhh, but does say VS2017 produce a smaller executable file, or a faster executable? I am pleased Igor cares about individual 1% improvements - they stack up to significant savings. However I agree for our work usage security is more important.

> does say VS2017 produce a smaller executable file, or a faster executable?

If I recall correctly, Igor once said that he tested the new VS compiler and it produced neither smaller nor faster executables. I believe there was almost no difference.

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

#87

Post by iknowstuff »

mr_toad wrote: post #77
nsuser3 wrote: post #75

Earlier quoted context omitted.

> Because 7zip is not a good auto update software Updates should be handled by the OS anyway IMO

Can’t see that happening on Windows soon, if ever.

The Microsoft Store correctly auto-updates apps from the store.

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

#88

Post by raimue »

eisa01 wrote: post #51

Are there any good alternatives to 7-zip we can use instead?

For extraction, use bsdtar from libarchive. It supports various container and compression formats. I never looked back to GNU tar, bsdtar is vastly superior.

https://github.com/libarchive/libarchive/wiki/LibarchiveForm...

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

#89

Post by platinumrad »

steveklabnik wrote: post #81
platinumrad wrote: post #70

Earlier quoted context omitted.

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.

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) much of the time the person saying "RIIR" admits to not even being a Rust programmer themselves. I think it's just a side effect of Rust (justifiably) emphasizing safety, and by extension security, in its presentation, and the tendency of some people to conflate the elimination of a certain class of vulnerabilities with the elimination of all vulnerabilities. To be fair, this poster didn't make this mistake.

Edit: Another mistake that some people make after being introduced to Rust is assume that languages that don't explicitly emphasize memory safety in their presentation aren't memory safe. This poster comes across as potentially making this mistake.

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

#90

Post by RaleyField »

user5994461 wrote: post #82
RaleyField wrote: post #74

Earlier quoted context omitted.

Why am I getting downvoted? I sincerely wonder what is so objectionable in my comment. Most uses of 7-zip are one-off events that last around a minute long. Most users aren't decompressing terabyte-range files. It makes no fracking difference to users if they have to wait 5 minutes or 1 minute. But it makes a difference if they receive 7z archive and get their bank account cleaned because the author prematurely optim…

Consider that it was misplaced to suggest a 500% performance drop. It's used to extract large archives, backups, videos, documents. Folks don't want it to take half an hour instead of a few minutes.

Thanks for replying, this explains things. I guess I extrapolated from my needs too much, I didn't consider users who do daily 10+ GB compressed backups.

I still wonder if there's an ethical dilemma that lies underneath this - is it fair to prioritize needs of users who use your tool in a different way (for backup jobs) over users that use your tool only occasionally, perhaps not even out of their own initiative (they were sent 7z file from a ostensibly trusted source).

Post reply on HN