Buffer overflow?

Matthew Dillon dillon at apollo.backplane.com
Thu Jul 31 22:15:31 PDT 2003


:..
:Seriously, if anyone could explain to me (a non-professional programmer)
:how it came to pass that buffer overflow is a non-trivial problem I would
:be truly grateful, since I've asked this before in several forums and I
:never got a real answer (that I could understand).
:
:Since this project seems primarily concerned with kernel design, are
:there any thoughts on how security could be designed into the kernel
:and isolated as much as possible from userland?
:
:This is a big topic, but the beginning of a project seems like a better
:place to consider security than at the other end.

    It's all historical.  The original C language library had functions
    like sprintf(), strcpy(), strcat()... none of which are bounded
    functions.  Hundreds of thousands of programmers grew up on those 
    functions and they are all now microsoft employees :-).

    Seriously, though, the C lib has new functions, e.g. snprintf(), and 
    the only way to avoid most buffer overflow problems is to use these
    bounded functions and never, ever use the unbounded functions, even
    if you *know* a particular use will not overflow a buffer.

    The second type of buffer overflow is an array index overflow, where
    an array index is incorrectly calculated or incorrectly bounded.  For
    example, consider the age-old misuse of malloc() where beginning 
    programmers would do something like:  str2 = malloc(strlen(str1)),
    which doesn't account for the \0 terminating the string, or programmers
    who check the high side but forget that they are using a signed index
    variable which could very well be negative.

    If just these two problem areas were cleaned up 99% of all buffer 
    overflow issues would disappear.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list