This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Super Lint (was: Unexecutable Stack / Buffer Overflow Exploits...)


I wrote:

> > Undecidability simply means that any correct program that attempts to
> > do certain kinds of analysis must return a three-valued answer: yes,
> > no, or "I can't tell".  gcc is already full of code that attempts to
> > solve undecidable problems ...

"Oliver Xymoron" writes:

> But writing a -Wsecure is harder. Whereas it's easy for a programmer to
> fix a "can't tell" initialization in a way that static analysis can figure
> out that it's been done, the same is not true for tracking security.

The same issues apply.  A tool will tell you what it can't figure out.

> Consider:
> 
> void foo(int i)
> {
> 	int j, k;
> 
> 	if(k=hardtocompute(i)) // always true?
> 	{
> 		j=k;
> 	}
> 
> 	use(j);
> }
> 
> vs
> 
> void foo(int i)
> {
> 	int j,k;
> 
> 	if(k=lookup_uid(i)) // always true?
> 	{
> 		j=k;
> 	}
> 
> 	setuid(j);
> }
> 
> In the first case, we can simply set j to some useful value to shut up the
> warning, but in the second what we're actually concerned about is
> validating lookup_uid. A system that punts and gives a warning when
> lookup_uid isn't transparent isn't really helping. 

Sure it is.  Since lookup_uid can't be completely analyzed, we don't
know whether it might return zero.  We simply say so.  The programmer
would then need to fix the code by adding an else clause.

> Your example about unreachable code is telling: we certainly wouldn't want
> the compiler to complain whenever it couldn't figure out when code was
> reachable.

For security analysis, you WOULD want the compiler to complain in all
cases where we can't prove that something undesirable might happen.

> If we want to statically detect things like potential buffer
> overflows (ie what we were originally talking about), it means we'll have
> to forecast through the loops that index said buffers, more than likely
> including global analysis of input variable domains, etc. The compiler now
> takes three years and 10 gig of memory to build itself, assuming it's not
> treating warnings as errors...

No, simply insert run-time bounds checking code in all places where
we can't prove that an overflow can't occur.  Compilers for other
languages than C work that way already.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]