enforce()?

[BCS]

Hello Vladimir,

> 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.

If I didn't write the DLL I'm calling, I'll assume it doesn't check stuff. 
If I didn't write the code calling my DLL, I'll assume it doesn't check stuff. 
Why should I assume that the documentation is right or that people will even 
read my documentation? Unless you can show me that this causes a perf problem, 
the benefit just isn't worth the cost.

>> 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.

OK, but just because there might be a risk in loading a DLL is no reason 
to not address other risk that you can deal with.

> 
> 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.

Good point, I might not check it exactly at the call site, but *I* will will 
check it because I will assume that any checks on the other side of a DLL 
interface are flawed, missing, broken or just flat wrong.

-- 
... <IXOYE><