@MBond2 said:
I’m reminded of the Sherlock Holmes story with the dancing man code - what one man can devise another may can decipher. That may not be an exact quote as it is entirely from memoryThe import for this particular problem is that any security scheme that you devise, I can always break.
If necessary, we can go into specifics on the approaches that you mention but that’s axiomatic. But the important question is how difficult will it be for me to do so and whether I have the skill. Ask the NSA how much motivated and skilled people can do.The conclusion is that you have to trust something at some point. And you should trust the OS and the security system built into it. And that means that you should assign an appropriate ACL and call it a day. Because every effort after that provides only illusory increases in security. If I have admin access, I can replace your driver with a decompiled version that omits your check if I want
Well, as i said, in this scenario lets assume that i can protect my files and processes from modification (since I’m already in kernel and we assume the attacker doesn’t have a driver, if he did then its obviously game over)
In this scenario, if i am checking the digital signature of the process that is sending me the IOCTL, you CANNOT bypass is, literally. Okay maybe if i used SHA-1 then there is a small chance, but if i am using a SHA-2 digital signature, you CANNOT, and i repeat, CANNOT bypass this without having some sort of super computer to forge my digital signature… I am more than happy to see if you can provide me any type of attack that can bypass my protection.
And again, we assume that the attacker doesn’t have a driver to begin with, and wants to use the functionality of my driver for exploit or something else, and we assume that i am properly protecting my processes and files using callbacks and minifilters, in this scenario i am 100% sure you cannot bypass this and communicate with my driver unless you break SHA-2…