Re: Compaq Alpha Bounds Checking

[crispin () CSE OGI EDU (Crispin Cowan)]

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