Re: Bounds Checking

From: Bob Beck (beckat_private)
Date: Tue Jul 21 1998 - 15:35:38 PDT

  • Next message: TTSG: "N-Base Vulnerability Advisory Followup"

    > [ language religious wars, machines with hardware bounds checking ]
    ...
    >
    > array.setvalue(...)) you could implement yourself some nice safe arrays. I
    > think this is much better than having the bounds checker built into the
    > compiler do something annoying and not under your control (by Murphy, the
    > opposite of what you'd like it to do) when bounds are overrun. It's secure
    > if the program quits when you pass it 10k 'X' characters looking for a
    > crash, but it's _elegant_ if the program deals with the error internally
    > rather than relying on the compiler's bounds checking code. It also gives
    > power to the programmer, which is the point of not using visual basic :).
    >
    
            "If the program deals with the error internally" - sounds like
    manual bounds checking to me. Sure, bounds enforcement, even in your
    own library, can stop the buffer overruns in your bad code (lets not
    talk about the libraries you linked with, etc. etc.). But will it do
    the right thing? What is the right thing to do when you get 10k of X
    characters? Is it to stop(or do arbitrary something) with a bounds
    checking exception? No. That's a bug. Might be you've prevented a
    buffer overrun, and might be in another circumstance that you've
    created a security problem by the fact that your program is no longer
    running or not doing what you expected it to be doing. Maybe a denial
    of service, maybe the fact that your program has gone away lets me
    pretend to be your program. Maybe your program was the front door that
    has now exited. Not having a buffer overrun is nice, but in and of
    itself solves nothing if the code isn't always doing the right thing.
    The right thing to do may be different for 10 different pieces of
    program - exiting, discarding the input, giving an error, logging the
    attempt, or notifying the admin to come after the source of the
    problem with a LART..  Improper handling of unexpected input is a bug,
    and "proper" is very context dependent.
    
            If you have to "do the right thing" in your unexpected input
    case, no bounds checking(language/compiler/library/class/whatnot) is
    going to do it for you. The programmer still has to know what the
    right thing to do is, and have the code identifying the exceptional
    cases and handling them.  Does it mean they can screw it up and count
    on the the bounds checking to have you exit?  perhaps, if
    implementation of the language isn't flawed, (heaven knows C++ and
    Java implementations are never flawed :) Are there languages where it
    may be easier to implement doing the right thing? Sure. since
    whatever's easier for you to do the right thing in is probably a
    decent choice. Will automatic <something happening> on bounds
    violations make programmers more or less careful about writing better
    code and dealing with it the "right way"?  I don't know about that
    one, particularly in the death-march-sell-it-now-fix-it-later modus
    operandi of an awful lot of modern software development.
    
            Cheers,
    
            -Bob
    
    --
    Bob Beck                                   Computing and Network Services
    beckat_private                           University of Alberta
    True Evil hides its real intentions in its street address.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:07:22 PDT