Endpoint Protection

Hi all,

I would like to report an issue which is likely to be caused by Symantec Endpoint Protection 12.1, namely UMEngx86.dll. It seems that SEP is somehow messing up the Windows kernel so that C++/CLI interop functionality implemented in the Visual Studio 2013 linker is not working anymore.

I have implemented a bridge in order to call into managed CLR code from native C++ code via C++/CLI wrapper classes. The process is described here (http://blogs.microsoft.co.il/sasha/2008/02/16/net-to-c-bridge/) in detail. The idea is that a truly native C++ library (without CLR) is linked against a C++/CLI library which forwards calls to C# code. Thereby, stubs are injected by the linker into the C++/CLI build which load the CLR before executing the managed code. In detail, the native bridge code references the IL bridge via a forward declaration in the header file, while in the source file of the native bridge, the actual IL bridge header file gets included via “#pragma managed”. The C++/CLI based IL bridge references a C# class via the gcroot<> template and performs the actual marshaling between managed and unmanaged objects.

While this approach looks a bit adventurous, it used to work perfectly with Visual Studio 2013 (Update 1) until some weeks ago, when the bridge suddenly stopped working when building for a 32-bit target. ( The x64 target still works!) Instead, the executable crashes at startup, before the main method is reached, with an exception (0xc0000005) within ntdll.dll caused by an attempt to write to a protected memory location. I suspect this is due to an update to SEP introducing the faulty version of the UMEngx86.dll. The stack trace is as follows, as provided by IDA Pro:

Address  Function                                   
-------  --------                                   
76FB019A _LdrpSnapThunk@36+101                      
76FC0E66 _LdrpSnapIAT@12+8D                          
76FC16D1 _LdrpHandleOneOldFormatImportDescriptor@12+93
76FC171E _LdrpHandleOldFormatImportDescriptors@12+1E
76FC1619 _LdrpProcessStaticImports@8+D5F            
76FC6ACD _LdrpInitializeProcess@8-8F4               
76FC5712 __LdrpInitialize@8+98F5                    
76FBBEB4 ntdll_LdrInitializeThunk+B

It’s impossible to debug the EXE with the VS debugger since the application crashes before the debugger gets attached, no matter if the debugger is set to Native or Mixed Mode.

Notably, UMEngx86.dll gets not loaded when running the 64-bit build, which still works perfectly. Also, people in this forum experienced related issues:

https://www-secure.symantec.com/connect/forums/windows-server-2008-r2-sp1-symantec-endpoint-protection-sepoct-updates-0xc0000005

This crash can be reproduced by building and running a tiny sample solution with less than 100 LOC (see attachment).

Any help will be greatly appreciated!

Best regards,

Andy

Attachment(s)

BridgeTest.zip   14 KB 1 version

What's the exact version of SEP? What components do you have installed? What OS?

Have you contacted Symantec about this so they can review? I would suggest a call to them.

Thanks for your reply.

The version is 12.1.2015.2015. The OS is Windows 7 SP1 Enterprise 64-bit. Installed components are Firewall, ITPMain, NTPMain, PTPMain, TruScan, SAVMain.

I contacted the Symantec support about the problem, they are still investigating.

The problem can 99% sure be attributed to UMEngx86.dll hooking into kernel functions. Try out the minimum repro code I provided: If the EXE is run with SEP installed and UMEngx86.dll present, UMengx86.dll is loaded during initialization and the crash in ntdll.dll occurs before the main method is reached. If the UMengx86.dll is simply renamed, the EXE does not load it at startup and everything works fine.

I contacted a Windows kernel developer and security specialist at Microsoft about the issue who confirmed to me that the stack trace strongly suggests outside interference with the kernel.

I believe it is in Symantec's very own interest to fix this problem quickly - not only because SEP appearently breaks the functionality of pretty much any software compiled with the VS2013 platform toolset which calls into C++/CLI code (a problem which will augment as Visual Studio 2013 is increasingly being used by software developers), but also because there is the possibility that this bug can be exploited for privilege escalation. This means that a tailored binary may be crafted by attackers to provoke the crash in order to inject malicious code into the system and start its execution with administrative rights. I have not looked into this problem enough to tell if this is possible or not, but it should be considered.

It should be noted that this error is not caused by a false positive in the virus definitions. SEP is not intentionally stopping the software from working because it is considered malware, but instead, SEP modifies internal kernel functions in a way which may lead to a crash in the Windows kernel when certain legitimate software is run (which is not classified as malware by SEP). This is clearly a bug and needs to be fixed.

I'd also like to note that I spent about two weeks finding out the root cause for the problem that production software which used to work perfectly at our company suddenly stopped working. (First, I suspected Windows kernel or Visual Studio updates, but they proved to be innocent.) I strongly urge the Symantec software engineers to double-check their code when messing around with Windows kernel internals. Tracking the problem down to SEP has already created massive costs for us. Hopefully, Symantec is able to fix this error soon.

The new SEP 12.1.4.1 release SEP 12 RU4 MP1 seems to have a fix for a similar issue.