Unmanaged Binary Intercepts .NET DLL Loads

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The .NET framework is vulnerable to DLL hijacking attacks due to its design, which allows malicious DLLs to be loaded instead of standard OS DLLs, compromising the security of .NET applications.

Innovation Solution

Implementing a hybrid application configuration where a .NET application is hosted on an unmanaged native binary process that intercepts and scans DLL loads using API hooks, performing security checks such as digital signature verification and database comparisons to prevent malicious DLLs from loading.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the application framework searches and loads shared libraries from the target directory, then the application can access required libraries, but malicious libraries can be loaded instead of standard OS libraries

Engineering Contradiction:

Improvelibrary loading capabilityVSAvoidDLL hijacking vulnerability

Core Design Contradiction:

Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The unmanaged executable binary performs preliminary security checks on shared libraries before the application framework attempts to load them. Hooks are installed to intercept library load requests, verify digital signatures, and check against known malicious libraries in advance, preventing malicious libraries from being loaded while allowing legitimate ones to proceed normally.

Inventive Principle:

Principle #10Preliminary action

2Reliability

If hooks are installed to intercept library loading, then security checks can be performed, but system complexity increases

Engineering Contradiction:

Improvesecurity verificationVSAvoidsystem architecture

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

An unmanaged executable binary acts as an intermediary layer between the application framework and the shared libraries. This intermediary hosts the managed library file, intercepts library loading requests through hooks, performs security verification, and either allows or blocks the loading process. This approach concentrates security functionality in a dedicated component rather than distributing complexity throughout the entire system.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS11481482B2Securing an application framework from shared library sideload vulnerabilities

Publication Date: 2022.10.25 MCAFEE LLC

AI summary

There is disclosed in one example a computing apparatus, including: a processor and a memory; an operating system; an application framework including instructions to search a target directory for one or more shared libraries and to attempt to load the one or more shared libraries if found; and an application including: a library file including a primary feature module to provide a primary feature of the application, the primary feature module structured to operate within the application framework, wherein the library file is not independently executable by the operating system; and an unmanaged executable binary to host the library file, wherein the unmanaged executable binary is not managed by the application framework, and includes hooks to intercept the application framework's attempt to load the one or more shared libraries, and to provide security services to the one or more shared libraries before permitting the application framework to attempt to load the one or more shared libraries.