In-memory code signing

Question

Since a lots of malicious code are running in memory-only, wouldn't it be possible to sign each eXecutable codes (functions etc) of each PE files and check before each new started thread the code (in-memory) is indeed signed to continue ?

With this system, if one signed process want to inject some of his code into another process (via VirtualAllocEx, WriteProcessMemory etc) it will be fine.

What are the flaws of my reasoning ? Can this mechanism be used in practice (with some change in the PE structure or in the OS) ?

ed; I intentionally omit scripting languages and the "in-memory signed code" feature that I propose is to be used of course in addition with functionalities like Windows Guard/AppLocker

Answer 1

If an attacker has an arbitrary write vulnerability, they can bypass any form of software-implemented in-memory code signing. They could modify the memory after the code has been verified but before it is executed (a classic TOCTOU vulnerability), or simply toggle whatever bit is used to verify integrity. The only way this would work is if the check was implemented in hardware, with the actual code being verified by the CPU itself. However, it is much easier simply to use standard access controls to prevent memory injection. On Linux for example, this can be done with the Yama LSM. This is possible because memory injection is mediated by the kernel. The injecting process must specify the target and request permission to read from or write to its memory. The kernel can simply refuse the request, forcing the malicious process to escalate privileges quite a bit to modify memory.