enforce()?

[Vladimir Panteleev]

On Mon, 21 Jun 2010 03:02:53 +0300, BCS <none at 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:vladimir at thecybershadow.net