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

31–40 of 121 posts

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

#31

Post by HorizonXP »

blibble wrote: post #28
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.

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

I know this probably isn't the answer you're looking for, but it might be worthwhile to maintain a parallel fork to enable these options for yourself/others. That way, folks that feel the same way you do can have their cake and eat it too. I realize that it's not an ideal solution though.

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

#32

Post by sidlls »

dingo_bat wrote: post #29
Jweb_Guru wrote: post #26

Earlier quoted context omitted.

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…

I disagree with people who think Rust is a savior, but it does have plenty of advantages in some areas over C and C++, especially for novices.

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

#33

Post by y4mi »

Tomte wrote: post #23
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.

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

So yeah, it is an official source. It's just outdated

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

#34

Post by sandos »

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.

Why is that asking too much? I realize paying for software is not something everyone wants, but doesnt the free versions of VS work for compiling 7-zip?

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

#35

Post by codetrotter »

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…

> 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 just as well.

But the contents of a file is what really determines the actual file type, though.

So if you decide to block RAR files, you should do that by looking at the magic number. Then you are good to go. And it's not like you have to write a lot of code or anything to do this. The standard 'file' utility in Unix is able to determine the type of a file -- often by looking exactly at the magic number.

Just like you would inspect the actual contents of a file if you were running an image hosting site -- and not trust whatever arbitrary filename the uploader told you that the file had.

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

#36

Post by throwaway12351 »

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.

Like blibble says, this is an absurd tradeoff given that 7zip's primary use case is unarchiving files downloaded from the public internet. Between that, the willful ignorance and dismissiveness of security measures displayed https://sourceforge.net/p/sevenzip/feature-requests/1270/, and the apparent need for you to keep pressuring him to enable each countermeasure one-by-one, I question the prudence of using 7zip at all. He is clearly a great developer, and I have no reason to suspect ulterior motives, but his actions don't engender trust.

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

#38

Post by landave »

codetrotter wrote: post #35
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…

> 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 just as well. But the contents of a file is what really determines the actual file type, though. So if you decide to…

Of course, but I would still strongly advise against this.

If you really cannot avoid implementing something like this, you should inspect the 7-Zip code in order to be 100% sure that the magic number detection in your filter is identical (or matches a superset) to the one from 7-Zip.

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

#39

Post by landave »

wolf550e wrote: post #37

Is there software running on Linux which is derived from the same source and is also vulnerable? Is this package vulnerable: https://packages.debian.org/sid/p7zip-rar https://packages.ubuntu.com/bionic/p7zip-rar ?

Just looked at both the packages source, and it looks like they are affected. At least all the vulnerable code is in the source package.

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

#40

Post by codetrotter »

landave wrote: post #38
codetrotter wrote: post #35

Earlier quoted context omitted.

> 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 just as well. But the contents of a file is what really determines the actual file type, though. So if you decide to…

Of course, but I would still strongly advise against this. If you really cannot avoid implementing something like this, you should inspect the 7-Zip code in order to be 100% sure that the magic number detection in your filter is identical (or matches a superset) to the one from 7-Zip.

> you should inspect the 7-Zip code in order to be 100% sure that the magic number detection in your filter is identical (or matches a superset) to the one from 7-Zip

CPP/7zip/Archive/Rar/RarHandler.cpp:

    #define SIGNATURE { 0x52 , 0x61, 0x72, 0x21, 0x1a, 0x07, 0x00 }
CPP/7zip/UI/Common/OpenArchive.cpp:

    const Byte kRarHeader[] = { 0x52 , 0x61, 0x72, 0x21, 0x1a, 0x07, 0x00 };
CPP/7zip/Archive/Rar/Rar5Handler.cpp:

    #define SIGNATURE { 0x52 , 0x61, 0x72, 0x21, 0x1a, 0x07, 0x01, 0 }
Those are the two magic numbers for RAR archive version 1.50 onwards and RAR archive version 5.0 onwards respectively, and those are the places they are referenced in the 7-zip source code. I looked at the source archive of the 18.05 version, downloaded from https://www.7-zip.org/a/7z1805-src.7z. I guess if you wanted to be really rigorous you'd look at previous versions as well. If the 7-zip project makes use of a version control system and that vcs supports the equivalent of git blame then that should not be too difficult of a task for whoever wanted to go to that extent of investigation.

And here is where one copy of the 'file' command identifies the same magic numbers as RAR archives:

https://github.com/file/file/blob/f0a725a13fe0c1b046d8e07057...

    0 string Rar!\x1a\7\0 RAR archive data
https://github.com/file/file/blob/f0a725a13fe0c1b046d8e07057...

    0 string Rar!\x1a\7\1\0 RAR archive data, v5
:)
Post reply on HN