We’ve seen it countless times before. A vendor designs a security product, but punches a hole in this shield to accommodate developers. Yet, I still love the irony of it.
Software Restriction Policies and AppLocker can be configured to whitelist DLLs. But LoadLibraryEx has a feature (LOAD_IGNORE_CODE_AUTHZ_LEVEL) to circumvent SRP and AppLocker. From the MSDN documentation:
If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.
I’ve blogged about a spreadsheet that creates a DLL in a temporary location, and loads it inside the Excel process with LoadLibrary. It’s easy to block this DLL with SRP or AppLocker. But now I found out it’s also easy to bypass this, much easier than what I’ve done before. I just have to replace a call to LoadLibrary with a call to LoadLibraryEx, and pass it argument LOAD_IGNORE_CODE_AUTHZ_LEVEL. That’s all it takes to bypass SRP and AppLocker.
Let it be clear that this only makes it possible to load arbitrary DLLs inside existing processes, it does not allow you to create a new process that SRP/AppLocker wouldn’t allow.
If you use SPR/AppLocker, should you worry? It depends against what risk you use it.
When you use SRP/AppLocker to prevent common malware or other unwanted programs from infecting your machine, there’s no problem (now). If you use it on corporate computers to prevent your users from using software you don’t support, there’s no problem.
But if you use SRP/AppLocker as a security layer against (skilled) evil haxors, then you have to be aware that there is a large hole in your security layer and that it’s easy to misuse. In that case, you should better look out for another whitelisting security layer without “designer holes”. Unless it turns out Microsoft has a (hidden) setting to disable this feature, but I’ve not found one.