
Microsoft didn’t sandbox Windows Defender, so I did - ingve
https://blog.trailofbits.com/2017/08/02/microsoft-didnt-sandbox-windows-defender-so-i-did/
======
xpaulbettsx
I mean, the reason is almost certainly for performance reasons - would've been
interesting to see the hit that sandboxing takes here to something like `npm
install` (aka something that does lots and lots of file creates / writes)

~~~
Kenji
"Performance reasons" meanwhile I kid you not when I say that the Antimalware
Executable of Microsoft swallows about half my CPU performance when I am
downloading, unzipping, executing files. They could have implemented their
antivirus in JavaScript and it wouldn't have mattered.

~~~
adzm
implemented in JavaScript... something like this?

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

> The core component of MsMpEng responsible for scanning and analysis is
> called mpengine. Mpengine is a vast and complex attack surface, comprising
> of handlers for dozens of esoteric archive formats, executable packers and
> cryptors, full system emulators and interpreters for various architectures
> and languages, and so on. All of this code is accessible to remote
> attackers.

> NScript is the component of mpengine that evaluates any filesystem or
> network activity that looks like JavaScript. To be clear, this is an
> unsandboxed and highly privileged JavaScript interpreter that is used to
> evaluate untrusted code, by default on all modern Windows systems. This is
> as surprising as it sounds.

~~~
digi_owl
Time we bring back the C64 design, with no internal storage?

~~~
syrrim
And no networking.

~~~
retox
Try TempleOS, though a scamp from /g/ implemented a full network stack, along
with video players, etc.

~~~
digi_owl
And thus the first shim was formed...

------
na85
Can antimalware suites remain effective if they are sandboxed ?

Seems to me that the "system police", as it were, needs access to the system
it is policing.

~~~
tptacek
The scanning engine of an AV system is like the render process of a browser.
The browser itself has tentacles all over the system, but most of the danger
is in parsing and executing untrusted code, and that subsystem _doesn 't_ have
a lot of tentacles.

~~~
tyoma
The browser and renderer is a perfect analogy. Only the scanning code that
contains the format parsers, emulators, etc, needs to be sandboxed.

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

This doesn't make sense to me. It may have been easier to accomplish within
the author's skillset, but it seems to me that the more beneficial approach
would be to modify Tavis’ code to report the correct version of Windows.

~~~
tyoma
Tavis's code ran on Linux and hooked the import table of Defender's scanning
engine to report Windows XP as the underlying Windows version [1].

Originally the author didn't hook and let Defender call the native version
check APIs, which (correctly) reported Windows 10. Apparently there was extra
initialization code in that case that failed to run in a sandbox. The fix was
to reproduce the hooking code, in Rust, to report XP as the underlying Windows
version.

[1]
[https://github.com/taviso/loadlibrary/blob/master/peloader/w...](https://github.com/taviso/loadlibrary/blob/master/peloader/winapi/Version.c#L43)

~~~
londons_explore
Sounds likley that impersonating an old windows version would probably disable
various security features.

------
aneutron
What's most surprising is that, even though they have all the bad publicity
they could possibly get (security wise), they still chose not to go from
scratch working on a new secure solution (They have smart people working there
for sure), but chose to continue modifying an older codebase of a product they
probably bought 10 years ago (Only explanation I can think of why you'd run so
much untrusted code, at system level).

------
honestoHeminway
Even Sandboxing is no longer the golden grail it once was, after all, you can
still milk the machine for one of the ressources (computation power) without
leaving the sandbox.

Just tangential, but [are we sure], we added enough obnoxious UI-Dialog so
that the usual user will [Allow everything ?] once shelled to oblivion with
[Can you Confirm] boxes? After all, real secure Security, is when you shirk
the responsibilty as fast as possible by getting a User to act dumb or get
some overworked [Administrator started]?

------
nickpsecurity
Anyone got links to sites that try to aggregate and/or compare the various
sandboxing solutions in Windows that are open-source?

~~~
dguido
I think the only solution you want to use are AppContainers. AppJailLauncher
(our code) wraps them to make taking advantage of AppContainers easier.

I think the one other useful sandboxing-related tool for Windows comes from
Project 0, and they are for assessing the security of a product that uses one:
[https://github.com/google/sandbox-attacksurface-analysis-
too...](https://github.com/google/sandbox-attacksurface-analysis-tools)

~~~
AndrewCHM
Do you know of any good starting points for documentation/information for
AppContainers? I'm finding it hard sifting through irrelevant news articles
and somewhat-relevant-but-still-irrelevant microsoft/docker marketing
statements

~~~
dguido
Both AppJailLauncher and AppJailLauncher-rs have a good overview of how to use
them in their source code!

------
j_s
_a Rust-based framework to contain untrustworthy apps in AppContainers [...]
wrap the I /O of an application behind a TCP server_

 _as well as thoughts about Rust on Windows._

------
RachelF
While this is an interesting exercise, it ignores the fact that the anti-virus
apps run with SYSTEM privileges for a reason: they need to access all the
files on the machine.

Running Windows Defender in a sandbox will mitigate its own vulnerabilities,
but also make it easy for viruses to hide from it.

~~~
taviso
That is not ignored, the article includes a simple architecture diagram that
explains the standard solution to problems like this. In the diagram, you can
see that there is a privileged process (labeled parent) and a sandboxed
process (labeled child). The sandboxed process inherits a readonly handle to
the file to scan and a handle to a pipe to communicate the scan result to the
parent.

If the sandboxed process is compromised, all you can do is read a file that
you already had access to (because it's your exploit), and lie about the scan
result. That is not terribly exciting.

As the parent process doesn't do very much other than setup handles and read
simple results from the sandboxed process, it is significantly harder to
compromise.

This is the same model that browsers use. Your browser needs access to all
your files to manage Downloads and so on, but all the dangerous stuff happens
in the sandboxed renderer process. It is not "easier to hide from it", because
the process that intercepts i/o still runs at the same privilege.

~~~
RachelF
I was wrong. Thanks for your clear explanation, taviso.

------
stcredzero
I had a long talk with one of the Punkbuster engineers many years ago, and his
take on sandboxing was: It's like you're now standing in a deep pit, and your
enemies are up there at ground level, where they get to peek down into your
hole and throw rocks at you whenever you want.

~~~
londons_explore
Except, without sandboxing, your enemy is on ground level, you are privileged
(up on a hill), yet they can lob pandora's box in your direction, and you'll
helpfully open it from your almighty position of power on top of the hill...

~~~
stcredzero
So in other words, it's damned if you do, damned if you don't.

------
nanoscopic
This is a great example of why compiled applications with no sourcecode are
harmful and prevent advancement.

If the sourecode for Windows Defender was mostly open source, with only
critical portions linked in, then it would be possible to improve the portions
that integrate the libraries into the system without moving each process used
by it into some sort of wrapper.

There is not even a need for the sourcecode to be "free", merely that it is
able to be viewed and alterations contributed back to be available to anyone
who has paid for Windows.

