Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

The truth is rarely pure, and never simple. -- Oscar Wilde

rocksolid / Security / Re: Antivirus software increases your security, or not ?

* Antivirus software increases your security, or not ?Guest
`* Re: Antivirus software increases your security, or not ?AnonUser
 `- Re: Antivirus software increases your security, or not ?AnonUser

Subject: Antivirus software increases your security, or not ?
From: Guest
Organization: RetroBBS II
Date: Tue, 5 Jun 2018 04:44 UTC
Path: rocksolid2!.POSTED.localhost!not-for-mail
From: (Guest)
Subject: Antivirus software increases your security, or not ?
Date: Tue, 05 Jun 2018 04:44:43 +0000
Organization: RetroBBS II
Lines: 84
Message-ID: <pf54fr$rf0$>
Reply-To: Guest <>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 5 Jun 2018 04:44:43 -0000 (UTC)
Injection-Info:; posting-host="localhost:";
logging-data="28128"; mail-complaints-to=""
User-Agent: FUDforum 3.0.7
X-FUDforum: d41d8cd98f00b204e9800998ecf8427e <300436>
View all headers
Well, in this case at least it does not:

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

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


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


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

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.

F-Secure Corporation would like to thank "landave" for
bringing this issue to our attention. Date Issued: 2018-06-01

Posted on RetroBBS II

Subject: Re: Antivirus software increases your security, or not ?
From: AnonUser
Organization: RetroBBS2 for Tor
Date: Mon, 29 Oct 2018 14:09 UTC
References: 1
Path: rocksolid2!rocksolid0!rocksolid3!.POSTED.localhost!not-for-mail
From: AnonU...@retrobbs2.i2p (AnonUser)
Subject: Re: Antivirus software increases your security, or not ?
Date: Mon, 29 Oct 2018 14:09:06 -0000 (UTC)
Organization: RetroBBS2 for Tor
Message-ID: <e49e12ffa62f4e4a5a576c712fa4e33b$1@dkzerogt6z6ybhcj.onion>
References: <pf54fr$rf0$>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 29 Oct 2018 14:09:06 -0000 (UTC)
Injection-Info:; posting-host="localhost:";
logging-data="22277"; mail-complaints-to=""
View all headers
Microsoft reacts to the underlying problem. You know that there is a problem if the software vendor sandboxes his product:

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:


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

Subject: Re: Antivirus software increases your security, or not ?
From: AnonUser
Organization: Rocksolid Light
Date: Tue, 30 Oct 2018 01:01 UTC
References: 1 2
Path: rocksolid2!.POSTED.!not-for-mail
From: AnonU...@rslight.i2p (AnonUser)
Subject: Re: Antivirus software increases your security, or not ?
Date: Tue, 30 Oct 2018 01:01:35 -0000 (UTC)
Organization: Rocksolid Light
Message-ID: <3bd455570c4f15fbae1af957c48dd2d4$>
References: <pf54fr$rf0$> <e49e12ffa62f4e4a5a576c712fa4e33b$1@dkzerogt6z6ybhcj.onion>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 30 Oct 2018 01:01:35 -0000 (UTC)
Injection-Info:; posting-host="";
logging-data="21653"; mail-complaints-to=""
View all headers
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.

Microsoft didn’t sandbox Windows Defender, so I did
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.

The Borrow Checker. The concept of ownership is how Rust achieves memory safety. Understanding how the borrow checker works was fraught with cryptic, unique errors and took hours of reading documentation and tutorials. In the end it was worth it: once it “clicked,” my Rust programming dramatically improved.

Vectors. In C++, std::vector can expose its backing buffer to other code. The original vector is still valid, even if the backing buffer is modified. This is not the case for Rust’s Vec. Rust’s Vec requires the formation of a new Vec object from the “raw parts” of the old Vec.

Click here to read the complete article
rocksolid light 0.7.2