On Mon, 21 Jun 2010 03:02:53 +0300, BCS <n...@anon.com> wrote:
import my.dll;
void fn()
{
auto data = get.userUncheckedInput();
my.dll.doSomething(data); // if doSomething dosn't check it's
inputs, then this can cause a security flaw
}
Yes that's your dll's user's fault but adding the checks solves it even
so. To boot, it reduces your support cost (as long as people read error
message) and prevents the user from having to debug starting deep inside
your dll.
A well-designed application needs to validate unsafe user input exactly
once (assuming the process of validation is the same).
DLL interfaces must specify whether the input/output can be considered
safe or not.
Not doing so results in either security holes or redundant code.
And you can bet that every byte of data shipped back and forth via IPC
is validated more than an air traveler at a TSA checkpoint.
Obviously, no argument here.
As for the case where the dll is local, never attribute to malice that
which can be adequately explained by stupidity. Unless you have source,
you can't assume that the data coming out doesn't conation unvalidated
user input and you should always assume that someone malicious will get
ahold of that sooner or later.
Unless you have the source, you can't assume that simply loading the DLL
will not create a security hole.
Trusting the DLL but not trusting the data it gives you is a plausible
case. As I said before, this simply needs to be well-defined, and
validation doesn't have to happen exactly at the DLL boundary.
-- Best regards,
Vladimir mailto:vladi...@thecybershadow.net
