\nI can’t believe you people are actually asking for backdoors.\nIf an end user can do it, then so can a bad guy.\n<\/p>\n
In response to the requirement that all drivers on 64-bit Windows be signed,\none commenter suggested\n\nadding a backdoor that permits unsigned drivers<\/a>,\nusing some “obscure registry key”.\nBefore somebody can jump up and shouts “security through obscurity!”,\nthe commenter adds this parenthetical:\n“(that no application has privileges to do by default)”.\n<\/p>\n \nWhat does that parenthetical mean?\nHow do you protect a registry key from an application?\nAnd if applications don’t have privileges to modify a key,\nthen who does?\n<\/p>\n \nThe Windows security model is based on identity.\nApplications don’t have privileges.\nUsers have privileges.\nIf an application is running in your user context, then it can do\nanything you can,\nand that includes setting that “obscure registry key”.\n(This is a variation on\n“Your debugging code can be a security hole<\/a>“.)\nSame goes for DLLs.\nThere’s no such thing as something\n\nonly an individual program\/library can read\/write to<\/a>\n\nor do<\/a>.\nYou can’t check the “identity of the calling library” because\nyou can’t trust the return address.\nComing up with some other “magic encryption key” like the full path\nto the DLL won’t help either, because a key that anybody can guess\nwith 100% accuracy isn’t much of a key.\n<\/p>\n \nYes,\nUNIX has setuid,\nbut that still doesn’t make applications security principals.\nEven in UNIX, permissions are assigned to users, not to applications.\n<\/p>\n \nThat’s one of the reasons I get so puzzled when I hear people\nsay,\n“Windows should let me do whatever I want with my system<\/a>“,\nwhile simultaneously saying,\n“Windows should have used ACLs to prevent applications from\ndoing whatever they want with my system<\/a>.”\nBut when you are running an application,\nthe application is you<\/strong>.\nIf you can do it, then an application can do it\nbecause the application is you.\n<\/p>\n \nSome people want to extend the concept of security principal\nto a chunk of code.\n“This registry key can be written to only by this function.”\nBut how could you enforce this?\nOnce you let untrusted code enter a process,\nyou can’t trust any return addresses any more.\nHow else could you identify the caller, then?\n<\/p>\n \n“Well, the DLL when it is created is given a magic cookie\nthat it can use to prove its identity by passing that cookie\nto these ‘super-secure functions’.\nFor example,\n<\/p>\n \nand then the program can use the magic cookie to prove\nthat it is the caller.\nFor example, you could have\n \nThat won’t stop the bad guys for long.\nThey just have to figure out where the DLL saves that cookie\nand read it, and bingo, they’re now you.\n<\/p>\n \nTa-da, we now have a program that writes to that\nregistry key that \n“Well, sure, but if I combine that with the check-the-return-address\ntechnique, then that’ll stop them.”\n<\/p>\n \nNo, that doesn’t stop anybody. All the bad guy has to do is\nchange the \nYou can come up with whatever technique you want,\nit won’t do any good.\nOnce untrusted code has been granted access to a process,\nthe entire process is compromised and you cannot trust it.\nWorst case, the attacker just sets a breakpoint on\n \nThat’s why code is not a security principal.\n<\/p>\n\n\/\/ SECRET.DLL - a DLL that protects a secret registry key\nHANDLE g_hMagicCookie;\n\/\/ this function is called by means to be determined;\n\/\/ it tells us the magic cookie to use to prove our identity.\nvoid SetMagicCookie(HANDLE hMagicCookie)\n{\n g_hMagicCookie = hMagicCookie;\n}\n<\/pre>\nRegSetValueWithCookie(g_hMagicCookie, hkey, ...)<\/code>,\nwhere passing the cookie means ‘It’s me calling, please give\nme access to that thing that only I have access to.”\n<\/p>\n\n\/\/ bad-guy program\nint CALLBACK WinMain(...)\n{\n \/\/ call some random function from SECRET.DLL\n \/\/ so it gets loaded and the magic cookie gets\n \/\/ initialized.\n SomeFunctionFromSECRETDLL();\n \/\/ experimentation tells us that SECRET.DLL\n \/\/ keeps its magic cookie at address 0x70131970\n HANDLE hMagicCookie = *(HANDLE*)0x70131970;\n RegSetValueWithCookie(hMagicCookie, hkey, ...);\n return 0;\n}\n<\/pre>\nSECRET.DLL<\/code> was trying to protect.\nIt does it by merely waiting for SECRET.DLL<\/code> to receive\nits magic cookie, then stealing that cookie.\n<\/p>\nRegSetValueWithCookie(hMagicCookie, hkey, ...)<\/code>\nto code that hunts for a trusted address inside SECRET.DLL<\/code>\nand cooks up a fake stack so that when control reaches\nRegSetValueWithCookie<\/code>, everything in memory looks just\nlike a legitimate call to the function, except that the attacker\ngot to pass different parameters.\n<\/p>\nRegSetValueWithCookie<\/code>, waits for the breakpoint\nto hit, then edits the stack to modify the parameters and resumes\nexecution.\n<\/p>\n