
F-Secure Anti-Virus: Remote Code Execution via Solid RAR Unpacking - landave
https://landave.io/2018/06/f-secure-anti-virus-remote-code-execution-via-solid-rar-unpacking
======
fulafel
Are any AV vendors marketing themselves as more secure than the competition,
with technically founded evidence? Such as memory-safe PLs, VM or OS
sandboxes, running 3rd party native code in an emulator, bug bounties, etc.

Though probably their customers are mainly corporate "intranet" environments
where users open random content with Acrobat, Office etc and the high bit is
to just halve (1) the daily mass malware infections - which are not av focused
yet.

(1) or whatever the average AV detection rate is these days.

~~~
zaarn
From experience; no.

A/Vs are largely attack vectors, a huge number of malware already tries to
detect if an A/V is present and then uses it to get SYSTEM level privilege
fairly easily.

The number of actually good A/Vs is low and in my opinion, simply use
Microsoft Defender on Windows. For 0-days it's detection rate is, to my
knowledge, not significantly worse than any other A/V and unlike other
products they properly integrate into the system and don't disable almost all
security measures of the kernel like ASLR and friends so they can inject some
garbage DLL into any process.

The best protection for the intranet customer is training and regular software
updates. For the average user it's to tighten up security, lock them out and
then run regular updates.

~~~
kevin_b_er
So is Defender. The scanner runs as NT AUTHORITY/SYSTEM without any sandbox.
One flaw in the scanner is a widespread and nearly wormable exploit. You can
infect an entire company by just spamming them if you found an exploit in the
file type parsers it uses.

Here's a bug found by Project Zero. The researcher had trouble getting the
test case to Microsoft because Defender was running on their middleware boxes
and would automatically scan it and die from the exploit testcase.

[https://bugs.chromium.org/p/project-
zero/issues/detail?id=12...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1248)

~~~
tinus_hn
The standard way to deal with that is putting it into an encrypted zip with a
password like ‘virus’. That way it can’t be scanned.

~~~
tripzilch
True enough, but you don't do that before you run into it :)

------
nneonneo
Wow, this is a neat exploit. It breaks ASLR with a static payload, only
employing some decompression tricks to combine randomized addresses with fixed
ROP targets. I like the technique and I think it could be more generally
applied to file exploits.

------
brokenmachine
I've been using computers my entire life but this read like it was in Greek to
me. Very impressive that people out there actually understand all that stuff.
I'm not sure where to begin learning about that.

~~~
__m
Not Greek, Assembly :) C for the most part but Assembly gives you the
understanding

------
caf
The way the author uses the RAR decoder engine itself to mutate parts of an
existing (randomized) function pointer, defeating ASLR, is pretty damn neat.

------
youseecomrade
And MalwareBytes is still using 7zip 18.01

~~~
sebazzz
7-zip is licensed LGPL, so you should be able to replace the 7z support
library with a newer version.

~~~
TheDong
That is false. It's likely the end-user can update it, but the LGPL does not
prevent it from being impossible.

The LGPL makes it perfectly legal for the closed-source antivirus component to
not load any 7zip .so binary that is not signed by the antivirus vendor, of a
known hash, or so on... and the code loading said shared-object need not be
available or modifiable, just the code for the vulnerable .so they do ship.

~~~
saurik
The LGPL clearly states that a Combined Work which includes the the Library
must "1) Use a suitable shared library mechanism for linking with the Library.
A suitable mechanism is one that (a) uses at run time a copy of the Library
already present on the user's computer system, and (b) will operate properly
with a modified version of the Library that is interface-compatible with the
Linked Version." as well as insisting that the terms of the license under
which you distribute the Application "effectively do not restrict modification
of the portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications" <\- taken together, maybe (
_maybe_!) you could make an argument that your shared library loader was legit
while the code _using_ that shared library loader was evil (though that
_clearly_ violates the intention of this license in a way that is so blatant I
would be _shocked_ if a judge or a jury didn't shake their heads at your
claim), but then the rest of the anti-virus software wouldn't be able to be
distributed under a typical commercial license as modifications and reverse
engineering of that code would have to be allowed.

~~~
AstralStorm
I always wondered whether code signed deployment is not compliant with LGPL
and where the threshold lies.

Specifically, if forcing to sign a package with a different key (making it a
different package) for private purposes is enough, or if the redistribution
rights of the whole is required. Finally, if you cannot replace the software
because of code signing and no public debug mode, that seems incompatible
too...

------
graycat
What are each of

F-Secure

RAR

ASLR

massage the heap (what heap, where)

ROP chain

RarVM

etc.

~~~
bri3d
An article about something assuming domain knowledge? Say it ain't so!

F-Secure: an antivirus

RAR: an ancient archival format

ASLR: address space layout randomization, a system which loads code at
unpredictable locations to make exploits harder to write (as you don't know
where to jump)

ROP chain: Return Oriented Programming. A way to circumvent non-executable
memory protection and ASLR by manipulating the call stack to jump into to
existing executable code segments (called gadgets) and chain them together as
each returns to the next.

RarVM: an ill concieved mechanism allowing code to be embedded in RAR
archives.

~~~
graycat
Nice!!

