Earlier quoted context omitted.
> 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 w…
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.
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.