|Date:||August 17, 2006 / year-entry #279|
|Summary:||In the discussion of how to prevent non-"trusted" DLLs from using private OS resources, more than one person suggested having the LoadLibrary or FindResource function behave differently depending on who the caller is. But we already saw that you can't trust the return address and that you definitely shouldn't use the return address to make...|
In the discussion of how to prevent non-"trusted" DLLs from using private OS resources, more than one person suggested having the
All attackers have to do is find some other "trusted" code to do their dirty work. For example, the
"Well, I could add that same check to
I was just giving
No, you cannot impose security boundaries within a process. Once you let code run unchecked in your process, you have to treat the entire process as compromised. Even the parts that you thought were trustworthy.
Now, you might say, "Oh, we're not really making a security decision here. We just want to make circumventing the system so much hard work that somebody who goes to that much effort knows that they're doing something unsupported." But as commenter Duncan Bayne points out, that applies only to the first person to do it. They then make a library out of their technique, or publish it in a magazine article, and now anybody can use it without a struggle, and consequently without it crossing their mind that "Gosh, maybe this isn't such a great idea to use in production software."
<-- Back to Old New Thing Archive Index