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

21–30 of 121 posts

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

#21

Post by leeter »

landave wrote: post #15
blibble wrote: post #10

Earlier quoted context omitted.

I have previously read that for some reason the author disables most of the compiler options for things like ASLR and DEP I never managed to find out why edit: just found this: https://sourceforge.net/p/sevenzip/feature-requests/1270/ -- seems rather questionable considering MS give away the latest compilers for free

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…

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

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

#22

Post by landave »

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.

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

#23

Post by Tomte »

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.

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

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

#24

Post by dingo_bat »

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.

Of course same is true for modern cpp.

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

#25

Post by jessaustin »

nothrabannosir wrote: post #14
jessaustin wrote: post #8

Earlier quoted context omitted.

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.

As far as I understand the bug, this is not about running untrusted code (but: a parsing error resulting in state corruption). Unless you refer to the 3rd party lib (7z), used by virus scanners, to analyse rar files. But typically "untrusted code" means code that was supplied "at runtime", not at compile time (like a lib), so e.g. if a virus scanner would actually execute a .exe to evaluate its effects, or run javasc…

It is a very blurry line between running strange code and running library code against strange data. Mostly though, I'm trying to say that AV boxes should be outside the firewall.

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

#26

Post by Jweb_Guru »

dingo_bat wrote: post #24
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.

Of course same is true for modern cpp.

Modern C++ does not mandate that every value be a valid instance of its type wherever it is theoretically accessible, so I'm not sure why you're saying modern C++ fixes this. Actually, the fact that Rust does is something people somewhat regularly complain about. It is a heavy-handed performance / code complexity vs. safety tradeoff that certainly fixes this bug, which I think is a pretty reasonable thing to point out.

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

#27

Post by landave »

leeter wrote: post #21
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…

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.

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

#28

Post by blibble »

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.

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

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

#29

Post by dingo_bat »

Jweb_Guru wrote: post #26
dingo_bat wrote: post #24

Earlier quoted context omitted.

Of course same is true for modern cpp.

Modern C++ does not mandate that every value be a valid instance of its type wherever it is theoretically accessible, so I'm not sure why you're saying modern C++ fixes this. Actually, the fact that Rust does is something people somewhat regularly complain about. It is a heavy-handed performance / code complexity vs. safety tradeoff that certainly fixes this bug, which I think is a pretty reasonable thing to point ou…

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

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

#30

Post by WalterBright »

Jweb_Guru wrote: post #26
dingo_bat wrote: post #24

Earlier quoted context omitted.

Of course same is true for modern cpp.

Modern C++ does not mandate that every value be a valid instance of its type wherever it is theoretically accessible, so I'm not sure why you're saying modern C++ fixes this. Actually, the fact that Rust does is something people somewhat regularly complain about. It is a heavy-handed performance / code complexity vs. safety tradeoff that certainly fixes this bug, which I think is a pretty reasonable thing to point ou…

D also addresses buffer overflows in a mechanically checkable manner.
Post reply on HN