.NET Core vulnerability lets attackers evade malware detection

[silversurfer]

Content source

https://www.bleepingcomputer.com/news/security/net-core-vulnerability-lets-attackers-evade-malware-detection/

A vulnerability in the .NET Core library allows malicious programs to be launched while evading detection by security software.

This vulnerability is caused by a Path Traversal bug in Microsoft’s .NET Core library that allows malicious garbage collection DLLs to be loaded by users with low privileges.

This bug affects the latest stable release (3.1.x versions) of .NET Core. A fix is not currently available and could let attackers execute malicious code on a system without being readily detected by antivirus and EDR products. 1

Discovered by Paul Laîné of Context Information Security, the vulnerability is possible due to two main reasons:

• .NET Core lets you use a custom DLL as its garbage collector
• The environment variable “COMPlus_GCName” used for specifying a custom .NET garbage collector is not sanitized. Therefore any traversal characters (../) provided in the garbage collector path go unfiltered.

 

[SeriousHoax]

Not a vulnerability, says Microsoft

Because the exploitation of this mechanism requires that the attackers to have already the ability to set environment variables on the compromised system, Microsoft does not consider this a security vulnerability:


“Per MSRC, we do not consider this to be a security vulnerability. Exploiting this would require the adversary to modify the environment block, at which point they're already in control over other aspects of the application's execution.”, stated Microsoft’s representative in the GitHub issue reported by Laîné.


Laîné acknowledged in his original disclosure, “Having the ability to use a custom GC is a legitimate feature and should probably not be removed. However, the path traversal should be addressed in order to limit the use of a custom GC to only users with local administrator privileges, which should be the case for a server-side application or in a development environment.”


Given there is no trivial fix for this “legitimate” feature, there remains the potential for abuse in .NET heavy enterprise environments.