Is this 'super-lint' something that could/should be implemented in
something like 'cxref' and included in documentation?
PaulS
>
> From: kaih@khms.westfalen.de (Kai Henningsen)
> Subject: Super Lint (was: Unexecutable Stack / Buffer Overflow Exploits...)
> Date: 01 Jan 2000 18:21:00 +0200
>
> > cfmd@swipnet.se (Magnus Danielson) wrote on 01.01.00 in <20000101023746F.cfmd@swipnet.se>:
> >
> > > 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 01 2000 - 23:11:58 EST