Solar Designer wrote:
> > foo() {
> > char x[50];
> >
> > gets(x);
> > }
>
> I would _not_ expect this case to be covered by the compiler's bounds
> checking. This is in fact the reason I didn't use a strcpy() when
> demonstrating the bounds checking to you in my first post about ccc.
Understood. Unfortunately, this had the effect of hiding the things the compiler
doesn't do. I understand how the compiler would be unable to affect a
pre-compiled library, but I assumed that they would provide standard libraries
that had been compiled with bounds checking, and supply that version of the
library when you use the -check_bounds option. Since a very large proportion of
"array bounds" problems have to do with improper use of library functions, this
is a critical issue.
> This was so obvious for me that I forgot to mention this on the list,
> sorry. Now I realize that when saying "bounds checking" people often
> mean "complete protection", or close to that (with DoS in mind).
That's what I mean. That appears to be what Jones & Kelly meant:
http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html
If ccc is used to compile all library functions, then I would (reasonably?)
expect complete protection. StackGuard has a similar issue: if you link to
libraries that are not StackGuard-compiled, then vulnerabilities within the
library can be exploited. This is why we ship StackGuarded libraries from
http://immunix.org
> Speaking of the usage of gets() and such, even if the compiler was
> able to pass bounds checking information down to functions (which ccc
> doesn't do), it would at least require that you also recompile those
> functions themselves.
Ow! Bounds checking info doesn't get passed to functions? That DEFINITELY
limits the security effectiveness of this form of bounds checking. It
considerably limits the debugging effectiveness.
> Well, they could be more verbose in their description, yes. As for
> the "no protection"
> -- this wasn't meant as a security feature, but
> there's _some_ protection, it's just far from being complete.
Agreed :-)
> Finally, as this also goes to BugTraq this time, here's a piece of my
> first post on the subject that shows a case where bounds checking can
> work (and does indeed work) --
I tried Solar's code, and it does indeed "work", where "work" is defined as
"bounds checking on explicit array references that are local to a function."
Assorted other things produced all kinds of interesting side effects with
-check_bounds turned on :-) For example, this program:
[pbakke@spe85 ~]$ cat test3.c
foocpy(char * to, char * from, int count)
{
for (; count-- && *from; *to++ = *from++) {}
}
main() {
char a[25];
char x[100];
char b[12];
char y[100];
gets(a);
printf("a=>%s<, b=>%s<\n", a, b);
foocpy(b, a, 25);
/* strcpy(b, a); */
printf("a=>%s<, b=>%s<\n", a, b);
}
[pbakke@spe85 ~]$ ccc -check_bounds test3.c -o test3
test3.o: In function `main':
test3.o(.text+0x60): the `gets' function is dangerous and should not be used.
[pbakke@spe85 ~]$ ./test3
jjjjjjj
a=>jjjjjjj<, b=><
a=>jjjjjjj<, b=>jjjjjjj<
[pbakke@spe85 ~]$ ./test3
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
a=>jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj<, b=><
a=>jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj<,
b=>jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj<
I just massively overflowed the b[] array, entirely in my own code. ccc
-check_bounds didn't see it, either because it didn't pass the bounds down to the
function, or because it doesn't deal with pointer arithmetic.
If this is the intended behavior, and I misunderstood what is meant by "check
bounds", mea culpa :-)
Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:27 PDT