undefined | Better HN

0 pointsConst-me4y ago0 comments

> Every C++ app I’ve worked on that relies on a dll would checksum the dll against a list of acceptable versions

Never worked on any software which does that. Checking DLLs the way you described is a guaranteed way to break software after a windows update, or a driver update.

There’re many reasons why foreign DLLs can be loaded into your process. CreateRemoteThread is on the exotic side of things, other reasons are way more common.

Direct3D runtime loads user-mode DLLs implemented by nVidia/Intel/AMD/vmware/etc. MediaFoundation runtime loads quite a few DLLs, some of them third-party, implementing various transforms like codecs and containers. Many security-related software like firewalls load their DLLs into every process to check things. Some system software implements custom network protocols in DLLs, e.g. both HyperV and VMWare do that for their virtual networks. Apps like spy++ are using system-wide hooks, again that’s a foreign DLL loaded into every GUI program on that desktop. Many productivity apps like MS Office or Photoshop support scripting, users can often consume arbitrary DLLs in these scripts using LoadLibrary, COM and/or .NET.

0 comments

jbluepolarbear4y ago

I get what you mean. So those “public” are known vulnerabilities, the signed/checksumed dlls where typically vender dlls or our custom dlls that touched business logic and had to be resistant to injection.

Const-meOP4y ago

> So those “public” are known vulnerabilities

Yep, and there’s way too many of them. I forgot the most frequently used ones — shell extensions. Every time you embed a shell by calling GetOpenFileName/GetSaveFileName/ShBrowseForFolder/etc. you’re loading not just shell32.dll but also a bunch of third-party DLLs who adding their custom context menu entries, or rendering preview thumbnails for their file types, or similar. Technically, every such DLL can do whatever it pleases with your process, with both code and data.

> the signed/checksumed dlls where typically vender dlls or our custom dlls that touched business logic and had to be resistant to injection.

That’s better than nothing, but too many ways to workaround, still. I’m afraid the level of security you want is impossible for consumer-targeted software. Only possible sometimes in enterprise environments, where you can use legal/political methods to solve most of these issues: deny end users from being administrators of the computers they’re using, use group policies to restrict which software they may install, use other group policies to configure Windows security to be way more annoying but slightly more secure, stuff like that.

j / k navigate · click thread line to collapse