Re: Super Lint (was: Unexecutable Stack / Buffer Overflow

[Magnus Danielson]

From: [e-mail] (Kai Henningsen)
Subject: Super Lint (was: Unexecutable Stack / Buffer Overflow Exploits...)
Date: 01 Jan 2000 18:21:00 +0200

> [e-mail] (Magnus Danielson)  wrote on 01.01.00 in <[e-mail]>:
> 
> > Oh yes... like those that those who avoid strcpy by doing
> >
> >    memcpy(t, s, strlen(s)+1)
> >
> > I mean, memcpy is supposed to be safe, ain't it ;)
> 
> I guess what we _really_ need is some sort of super lint. That is, a  
> program that can analyze C code (others are fine, but C is the most  
> important by far) and highlights problematic points in the code.

We have needed a super lint for a long time, and improving on standard lint
is maybe not the the way to go. I forsee that eventually would such a tool
need to go to a higher level then _just_ matching known patterns (with some
dynamic knowledge) but the problem must be described in a much more generic
way and the patterns may be found in the sort of derivation that we use.
Such systems are possible to some degree. However, it's not here yeat and
there is a great feat to be accomplished (among those take the research on
AI related language development out in the open, a great barrier exist in
doing that). Some tools that could be the basis for such a thing allready
exist (out in the open, I've seen some in Debian for instance) but how well
they behave for these purposes is yeat to be found. What we are talking is
automatic code verification techniques based on well founded logic and
temporal logic. It's not directly a coffie break thing to do.

> And then there should be some sort of pseudo-comment which you can use to  
> explain properties of, say, pointed-to data, to possibly allow the super  
> lint to find out that the code is safe after all - except that somewhere  
> else, you violated those properties.
> 
> Note that this is NOT full program proof, which is far harder to get  
> right. You only want to prove that you don't overrun buffers and (while  
> we're at it) that you don't use unchecked data in critical places (what  
> Perl taint checking tests).

Trouble is, for some routines, there is "leakage" outside the immediate scope
for you to determine the actual bound of some pointers. It's really scary when
people start to do their own speciallized routines (like I still then to do)
for various scanning or generation purposes. The above example shows just how
things quickly go out of the "obviously right way to do it" and is not easilly
trapped. Another example would be

	{
		char * u, * v;

		for (u = s, v = t; *u != 0; u++, v++)
			*v = *u;
		*v = 0;
	}

which is just as broken as strcpy but it is not using anything of libc (and
those really defeat any libc bound method).

Let's not make this another obsfucated C contest, but let's just understand
that this lovely language holds many diffrent ways to acheive the same thing
and that you those have many ways of get something fucked up in many ways.
Also, what happends when it is partly in assembler?

Let's just conclude it is a nasty beast and we need to attack it from diffrent
angles. Some methods causes early detection (actually checking code somehow)
others are various sets of traps. It's a generic software stability problem
and really has not much to do with security and all security isn't a software
stability issue.

> This would not mean that your program actually does anything useful, only  
> that it's safe against some kinds of attack.

I would even say that it may not even do something correct (usefull or not)
but at least it doesn't break under some attacks. Security people really care
about both useabillity and unbreakability, but the useabillity issue is outside
the scope of such tool.

> And it would have zero runtime overhead.

As such yes, the necessary fixes may not have zero runtime overhead.

Yes, we need to screen code better, but it's a hairy problem and not all code
is screenable for various reasons. Also, a screening tool will most probably
spit out long long essays of troubles of various degree. We still need traps
and I think many will agree on that, even if it means compromising real time
properties. Having some service is better than having none (since it got
cracked).

Cheers,
Magnus