Well, in this case at least it does not:

https://www.f-secure.com/en/web/labs_global/fsc-2018-2

Security Advisories
FSC-2018-2: Remote Code Execution in F-Secure Windows
Endpoint Protection Products
Description

A memory handling error in F-Secure's file scanner
implementation can lead to remote code execution in F-Secure
Windows endpoint protection products.
Affected Products

Risk Level (Low/Medium/High/Critical): Critical

Consumer Products:

F-Secure SAFE for Windows

Corporate Products:

F-Secure Client Security
F-Secure Client Security Premium
F-Secure Server Security
F-Secure Server Security Premium
F-Secure PSB Server Security
F-Secure Email and Server Security
F-Secure Email and Server Security Premium
F-Secure PSB Email and Server Security
F-Secure PSB Workstation Security
F-Secure Computer Protection
F-Secure Computer Protection Premium

Platforms

Risk Level (Low/Medium/High/Critical): Critical

Windows

More Information

A vulnerability affecting most F-Secure Windows endpoint
protection products was discovered whereby scanning a
maliciously crafted RAR archive can lead to arbitrary code
execution. The vulnerability can be exploited both locally
for privilege escalation as well as remotely if the local
user is tricked to download a maliciously crafted archive. A
successful attack will result in the attacker gaining full
control of the system.

This issue and a Proof-of-Concept exploit was reported
privately to F-Secure as part of our Vulnerability Reward
Program. No known attacks have been reported or observed in
the wild.

Mitigating Factors

This issue has been fixed by our products' automatic update
mechanisms. Only if the automatic updates have been
explicitly turned off, do users need to trigger an update
manually.

In products F-Secure Email and Server Security, F-Secure
Email and Server Security Premium and F-Secure PSB Email
Security, the email scanning part does not make use of the
vulnerable component.

User interaction is required prior to successful
exploitation. The product setting of "Scan inside compressed
files (zip, arj, lzh, ...)" must be enabled to trigger
archive scanning.

F-Secure's products for Linux and Mac are not affected by
this issue.
Credits

F-Secure Corporation would like to thank "landave" for
bringing this issue to our attention.

Date Issued: 2018-06-01

Posted on RetroBBS II

Microsoft reacts to the underlying problem. You know that there is a
problem if the software vendor sandboxes his product:

https://www.bleepingcomputer.com/news/microsoft/microsoft-sandboxes-windows-defender/

Microsoft Sandboxes Windows Defender
By Ionut Ilascu

October 29, 2018 06:37 AM 0

As the infosec community talked about potential cyber attacks leveraging
vulnerabilities in antivirus products, Microsoft took notes and started to
work on a solution. The company announced that its Windows Defender can
run in a sandbox.

Antivirus software runs with the highest privileges on the operating
system, a level of access coveted by any threat actor, so any exploitable
vulnerabilities in these products add to the possibilities of taking over
the system.

By making Windows Defender run in a sandbox, Microsoft makes sure that the
security holes its product may have stay contained within the isolated
environment; unless the attacker finds a way to escape the sandbox, which
is among the toughest things to do, the system remains safe.
Remote code execution flaws

Windows Defender has seen its share of vulnerability reports. Last year,
Google's experts Natalie Silvanovich and Tavis Ormandy announced a remote
code execution (RCE) bug severe enough to make Microsoft release an
out-of-band update to fix the problem.

In April this year, Microsoft patched another RCE in Windows Defender,
which could be abused via a specially crafted RAR file. When the antivirus
got to scanning it, as part of its protection routine, the would trigger,
giving the attacker control over the system in the context of the local
user.

Microsoft is not aware of any attacks in-the-wild actively targeting or
exploiting its antivirus solution but acknowledges the potential risk
hence its effort to sandbox Windows Defender.
Turn on sandboxing for Windows Defender

The new capability has been gradually rolling out for Windows Insider
users for test runs, but it can also be enabled on Windows 10 starting
version 1703.

Regular users can also run Windows Defender in a sandbox if they have the
operating system version mentioned above. They can do this by enabling
the following system-wide setting from the Command Prompt with admin
privileges:

setx /M MP_FORCE_USE_SANDBOX 1

Restarting the computer is necessary for the setting to take effect.
Reverting the setting is possible by changing the value for forcing
sandboxing to 0 (zero) and rebooting the system.
Sandboxing Windows Defender

Forcing an antivirus product to work from an insulated context is no easy
thing to do due to the app's need to check a large number of inputs in
real time, so access to these resources is an absolute requirement. An
impact on performance is a likely effect of this.

"It was a complex undertaking: we had to carefully study the implications
of such an enhancement on performance and functionality. More importantly,
we had to identify high-risk areas and make sure that sandboxing did not
adversely affect the level of security we have been providing," the
official announcement reads.

Despite the complexity of the task, Microsoft was not the first to sandbox
Windows Defender. Last year, experts from security outfit Trail of Bits,
who also specialize in virtualization, created a framework that could run
Windows applications in their own containers. Windows Defender was one of
the projects that Trail of Bits was able to containerize successfully and
open-sourced it.
AVs are as susceptible to flaws as other software

Despite their role on the operating system, security products are
susceptible to flaws just like other complex software. Windows Defender is
definitely not the only one vulnerable.

In 2008, security researcher Feng Xue talked at BlackHat Europe about
techniques for finding and exploiting vulnerabilities in antivirus
software, referencing bugs as old as 2004.

Xue pointed out that the flaws in this type of software stem from the fact
that it has to deal with hundreds of files types that need to be checked
with components called content parsers. A bug in one parser could
represent a potential path on the protected system.

Six years later, another researcher, Joxean Koret, took the matter further
and showed just how vulnerable are the defenders of the computer systems,
and let the world know that exploiting them "is not different to
exploiting other client-side applications."

His analysis at the time on 14 antivirus solutions on the market revealed
dozens of vulnerabilities that could be exploited remotely and locally,
including denial of service, privilege escalation, and arbitrary code
execution. His list included big names like Bitdefender and Kaspersky.

Antivirus developers do not leave their customers high and dry and audit
their products constantly. The result is patching any of the bugs
discovered during the code review and improving the quality assurance
process for finer combing for potential flaws.
--
Posted on RetroBBS II

Thanks for posting this article. It's amazing to me all the ways there are
to exploit a program.

Here's the article of the person who sandboxed it before Microsoft did.

https://blog.trailofbits.com/2017/08/02/microsoft-didnt-sandbox-windows-defender-so-i-did/

Microsoft didn’t sandbox Windows Defender, so I did
POSTAUGUST 2, 201716 COMMENTS
Microsoft exposed their users to a lot of risks when they released Windows
Defender without a sandbox. This surprised me. Sandboxing is one of the
most effective security-hardening techniques. Why did Microsoft sandbox
other high-value attack surfaces such as the JIT code in Microsoft Edge,
but leave Windows Defender undefended?

As a proof of concept, I sandboxed Windows Defender for them and, am now
open sourcing my code as the Flying Sandbox Monster. The core of Flying
Sandbox Monster is AppJailLauncher-rs, a Rust-based framework to contain
untrustworthy apps in AppContainers. It also allows you to wrap the I/O of
an application behind a TCP server, allowing the sandboxed application to
run on a completely different machine, for an additional layer of
isolation.

In this blog post, I describe the process and results of creating this
tool, as well as thoughts about Rust on Windows.

Flying Sandbox Monster running Defender in a sandbox to scan a WannaCry
binary.

The Plan
Windows Defender’s unencumbered access to its host machine and
wide-scale acceptance of hazardous file formats make it an ideal target
for malicious hackers. The core Windows Defender process, MsMpEng, runs as
a service with SYSTEM privileges. The scanning component, MpEngine,
supports parsing an astronomical number of file formats. It also bundles
full-system emulators for various architectures and interpreters for
various languages. All of this, performed with the highest level of
privilege on a Windows system. Yikes.

This got me thinking. How difficult would it be to sandbox MpEngine with
the same set of tools that I had used to sandbox challenges for the CTF
community two years ago?

The first step towards a sandboxed Windows Defender is the ability to
launch AppContainers. I wanted to re-use AppJailLauncher, but there was a
problem. The original AppJailLauncher was written as a proof-of-concept
example. If I had any sense back then, I would’ve written it in C++ Core
rather than deal with the pains of memory management. Over the past two
years, I’ve attempted rewriting it in C++ but ended up with false starts
(why are dependencies always such a pain?).

But then inspiration struck. Why not rewrite the AppContainer launching
code in Rust?

Building The Sandbox
A few months later, after crash coursing through Rust tutorials and
writing a novel of example Rust code, I had the three pillars of support
for launching AppContainers in Rust: SimpleDacl, Profile, and WinFFI.

SimpleDacl is a generalized class that handles adding and removing simple
discretionary access control entries (ACE) on Windows. While SimpleDacl
can target both files and directories, it has a few setbacks. First, it
completely overwrites the existing ACL with a new ACL and converts
inherited ACEs to “normal” ACEs. Also, it disregards any ACEs that it
cannot parse (i.e. anything other than AccessAllowedAce and
AccessDeniedAce. Note: we don’t support mandatory and audit access
control entries.).
Profile implements creation of AppContainer profiles and processes. From
the profile, we can obtain a SID that can be used to create ACE on
resources the AppContainer needs to access.
WinFFI contains the brunt of the functions and structures winapi-rs
didn’t implement as well as useful utility classes/functions. I made a
strong effort to wrap every raw HANDLE and pointer in Rust objects to
manage their lifetimes.
Next, I needed to understand how to interface with the scanning component
of Windows Defender. Tavis Ormandy’s loadlibrary repository already
offered an example C implementation and instructions for starting an
MsMpEng scan. Porting the structures and function prototypes to Rust was a
simple affair to automate, though I initially forgot about array fields
and function pointers, which caused all sorts of issues; however, with
Rust’s built-in testing functionality, I quickly resolved all my porting
errors and had a minimum test case that would scan an EICAR test file.

The basic architecture of Flying Sandbox Monster.

Our proof-of-concept, Flying Sandbox Monster, consists of a sandbox
wrapper and the Malware Protection Engine (MpEngine). The single
executable has two modes: parent process and child process. The mode is
determined by the presence of an environment variable that contains the
HANDLEs for the file to be scanned and child/parent communication. The
parent process populates these two HANDLE values prior to creating an
AppContainer’d child process. The now-sandboxed child process loads the
malware protection engine library and scans the input file for malicious
software.

This was not enough to get the proof-of-concept working. The Malware
Protection Engine refused to initialize inside an AppContainer. Initially,
I thought this was an access control issue. After extensive differential
debugging in ProcMon (comparing AppContainer vs non-AppContainer
execution), I realized the issue might actually be with the detected
Windows version. Tavis’s code always self-reported the Windows version
as Windows XP. My code was reporting the real underlying operating system;
Windows 10 in my case. Verification via WinDbg proved that this was indeed
the one and only issue causing the initialization failures. I needed to
lie to MpEngine about the underlying Windows version. When using C/C++, I
would whip up a bit of function hooking code with Detours. Unfortunately,
there was no equivalent function hooking library for Rust on Windows (the
few hooking libraries available seemed a lot more “heavyweight” than
what I needed). Naturally, I implemented a simple IAT hooking library in
Rust (32-bit Windows PE only).

Introducing AppJailLauncher-rs
Since I had already implemented the core components of AppJailLauncher in
Rust, why not just finish the job and wrap it all in a Rust TCP server? I
did, and now I’m happy to announce “version 2” of AppJailLauncher,
AppJailLauncher-rs.

AppJailLauncher was a TCP server that listened on a specified port and
launched an AppContainer process for every accepted TCP connection. I
tried not to reinvent the wheel, but mio, the lightweight IO library for
Rust, just didn’t work out. First, mio’s TcpClient did not provide
access to raw “socket HANDLEs” on Windows. Second, these raw “socket
HANDLEs” were not inheritable by the child AppContainer process. Because
of these issues, I had to introduce another “pillar” to support
appjaillauncher-rs: TcpServer.

TcpServer is responsible for instantiating an asynchronous TCP server with
a client socket that is compatible with STDIN/STDOUT/STDERR redirection.
Sockets created by the socket call cannot redirect a process’s standard
input/output streams. Properly working standard input/output redirection
requires “native” sockets (as constructed via WSASocket). To allow the
redirection, TcpServer creates these “native” sockets and does not
explicitly disable inheritance on them.

My Experience with Rust
My overall experience with Rust was very positive, despite the minor
setbacks. Let me describe some key features that really stood out during
AppJailLauncher’s development.

Cargo. Dependency management with C++ on Windows is tedious and complex,
especially when linking against third-party libraries. Rust neatly solves
dependency management with the cargo package management system. Cargo has
a wide breadth of packages that solve many common-place problems such as
argument parsing (clap-rs), Windows FFI (winapi-rs et. al.), and handling
wide strings (widestring).

Built-in Testing. Unit tests for C++ applications require a third-party
library and laborious, manual effort. That’s why unit test are rarely
written for smaller projects, like the original AppJailLauncher. In Rust,
unit test capability is built into the cargo system and unit tests
co-exist with core functionality.

The Macro System. Rust’s macro system works at the abstract syntax tree
(AST) level, unlike the simple text substitution engine in C/C++. While
there is a bit of a learning curve, Rust macros completely eliminate
annoyances of C/C++ macros like naming and scope collisions.

Debugging. Debugging Rust on Windows just works. Rust generates WinDbg
compatible debugging symbols (PDB files) that provide seamless
source-level debugging.

Foreign Function Interface. The Windows API is written in, and meant to be
called from, C/C++ code. Other languages, like Rust, must use a foreign
function interface (FFI) to invoke Windows APIs. Rust’s FFI to Windows
(the winapi-rs crate) is mostly complete. It has the core APIs, but it is
missing some lesser used subsystems like access control list modification
APIs.

Attributes. Setting attributes is very cumbersome because they only apply
to the next line. Squashing specific code format warnings necessitates a
sprinkling of attributes throughout the program code.