
7-Zip: From Uninitialized Memory to Remote Code Execution - landave
https://landave.io/2018/05/7-zip-from-uninitialized-memory-to-remote-code-execution/?hn
======
landave
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 just as
well.

On /r/sysadmin, someone even mentioned that a temporary solution might be to
block RAR files. By the same argument, this is unlikely to be effective.

2\. Almost all versions prior to 18.05 are affected. I manually checked
version 15.05 and 17.01, and they are definitely affected.

3\. Not only 7-Zip itself is affected, but essentially all software that uses
7z.dll as library to extract files. This includes various anti-virus software.
However, exploitation may be more difficult (though not impossible) if
ASLR&DEP is properly enabled (on all modules).

~~~
jessaustin
_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.

~~~
nothrabannosir
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 javascript found in a webpage.

To be fair to virus scanner vendors, the only way to mitigate this kind of bug
is NIH: don't use 3rd party libs, implement everything yourself. But then, of
course, without bugs yourself, as well :)

~~~
pfg
> To be fair to virus scanner vendors, the only way to mitigate this kind of
> bug is NIH: don't use 3rd party libs, implement everything yourself. But
> then, of course, without bugs yourself, as well :)

That is not the only way to mitigate such vulnerabilities. AV vendors have had
plenty of time to work on sandboxing parts of their scan engines that have
repeatedly been found to have vulnerabilities like this one. Somehow we've
arrived at a point where no one would recommend using a browser that doesn't
utilize sandboxing to some degree, but when it comes to security products, you
can count yourself lucky if they don't just run that code as SYSTEM. That
should really tell you all you need to know about the state of the AV
industry.

~~~
RaleyField
> no one

Plenty of people recommend Firefox despite it sharing processes between tabs.
More than 10 years after MS sandboxed IE.

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

~~~
fuzzy2
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.

~~~
wyday
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...](http://discuss.bootstrapped.fm/t/code-signing-certificate-
recommendation/5806/8?u=wyattoday)

Regular, non-EV code-signing certs, aren't as useful as they were when Vista /
Windows 7 were the main Windows OSes.

~~~
Boulth
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...](https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-smartscreen-
extended-validation-ev-code-signing-certificates/)

~~~
wyday
I didn’t say “not useful”. Clearly they’re useful. I said non-EV certs “aren’t
as useful”. Which is just a fact (as evidenced by the Smart Screen “reputation
boost” that EV certs get).

I already read that blog post. I’m person that linked to it in the forum post.

------
therealmarv
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/](http://www.7-zip.de/) is the official site and you
still download 16.04 there.

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

~~~
MereInterest
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.

~~~
superflyguy
Assuming I agree with you, what's the reason for not telling me about updates
when I run the app? What's the advantage of the decision they've taken which
is to not announce this?

~~~
MereInterest
Because even determining that there is an update available requires checking
against an outside source to see if an update is available. This requires
internet access, which requires handling network protocols, network security
and encryption, none of which have anything to do with file compression.
Increasing the scope of a project introduces additional failure modes, and a
larger security risk.

If a project already performs telemetry, or if they have developer
announcements, then the project has already increased its scope, and checking
for updates is a relatively minor addition. If it is a well-behaved stand-
alone application that doesn't make unwarranted external connections, then
checking for updates is a large increase of scope.

------
therealmarv
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...](https://landave.io/2018/01/7-zip-multiple-memory-corruptions-
via-rar-and-zip/)

[2]:
[https://sourceforge.net/projects/p7zip/files/p7zip/](https://sourceforge.net/projects/p7zip/files/p7zip/)

~~~
landave
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.

~~~
pkkm
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.

~~~
landave
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.

~~~
pkkm
"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.

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

------
wolf550e
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.debian.org/sid/p7zip-rar)

[https://packages.ubuntu.com/bionic/p7zip-
rar](https://packages.ubuntu.com/bionic/p7zip-rar)

?

~~~
chungy
Debian (and Ubuntu as a downstream) patched out issues already:
[https://www.debian.org/security/2018/dsa-4104](https://www.debian.org/security/2018/dsa-4104)

~~~
landave
That's right, they patched CVE-2017-17969, which affected ZIP decompression.
Interestingly, I believe they didn't patch CVE-2018-5996 (affecting RAR),
which I published [0] on January 23 together with CVE-2017-17969.

[0]: [https://landave.io/2018/01/7-zip-multiple-memory-
corruptions...](https://landave.io/2018/01/7-zip-multiple-memory-corruptions-
via-rar-and-zip/)

~~~
carey
The Debian security team doesn’t patch packages from the non-free repository,
like the 7-Zip RAR support:

[https://www.debian.org/security/faq#contrib](https://www.debian.org/security/faq#contrib)

That would have to wait for the maintainer to upload a new version and get it
into a stable release.

------
olinguito
Has anyone definitively confirmed that this vulnerability exists in 7-Zip
v9.20 (release) through v9.35 (beta)?

------
nebulous1
I have always used 7-Zip on Windows. Having done some reading now, the
author's general attitude towards the tradeoff between security and executable
size/speed have convinced me to try and not use it in the future. Thankfully I
rarely have to use Windows these days.

------
lengocthuong15
Hi all, In 18.01 Igor had fixed CVE-2018-5996 with adding some variable like
_errorMode or m_TablesOK. And in 18.05 I don't see this variables. Igor was
replace it by _solidAllowed to fix CVE-2018-10115. Does it fix for both
CVE-2018-5996 and CVE-2018-10115? Thank you

~~~
landave
I think this is correct. Since _solidAllowed is set to false at the beginning
of Code(), it will remain false if an exception occurs in the middle of
decoding (CVE-2018-5996). This will enforce PpmError being set to true for the
next item, which in turn will enforce the (possibly broken) PPMD state to be
reinitialized. In some sense, this means that the new bug fix is a
generalization of the first one, fixing both CVE-2018-5996 and CVE-2018-10115.

~~~
lengocthuong15
Thank you!

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

~~~
raimue
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...](https://github.com/libarchive/libarchive/wiki/LibarchiveFormats)

------
StapleHorse
I would never have found out this if it wouldn't for this post in HN. So
Thanks you for posting.

------
dsc_
This is why Cuckoo Sandbox uses sflock
([https://github.com/jbremer/sflock](https://github.com/jbremer/sflock)) :)

It sandboxes extraction.

------
SloopJon
I notice that the submission contains a "?hn" query arg, which I'm pretty sure
confuses the dupe detector.

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

~~~
user5994461
You need 7-zip to read tarball and zip on Windows.

------
visitorabc
Since Ubuntu and Debian are affected,so CentOS is affected too?

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

~~~
platinumrad
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.

~~~
steveklabnik
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.

~~~
platinumrad
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.

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

