Re: Public disclosure of discovered vulnerabilities
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


sci.crypt archive

Re: Public disclosure of discovered vulnerabilities

From: Andrew Swallow <am.swallow@btopenworld.com>
Date: Thu Jun 09 2005 - 15:55:54 CEST

Douglas A. Gwyn wrote:

> Larry Elmore wrote:
>
>> That does *not* mean better tools won't make it easier to
>> get equally good results.
>
>
> Better tools *do* make it easier to produce good products.
> However, we're seeing more crappy products. It isn't the
> tools.

The problem of buffer overruns is language independent - they
all suffer from it. Typed languages simply detect the problem.
Here is an example in a made up computer language. To work *all*
languages have to use the second more complex algorithm.

Managerial point, the more complex algorithm takes longer to run
and costs at least twice as much to write.

/* Example of bad code that will suffer buffer overruns *\
procedure STORE_DATA (integer DATA)

global POINTER, BUFFER (MAX_BUFFER)

POINTER = POINTER + 1
BUFFER (POINTER) = DATA

return

end procedure

/* Now how it should have been written */
/* programmer Andrew Swallow *\
procedure STORE_DATA (integer DATA)

global COUNT, POINTER, BUFFER (MAX_BUFFER)

COUNT = COUNT + 1
if COUNT >= MAX_BUFFER then

    print "Error buffer overflow"
    /* Recover by empting buffer *\
    call INITIALISE_BUFFER
    /* Also discards DATA *\

else

    POINTER = POINTER + 1
    /* Wrap round when you get to the end of the array *\
    if POINTER >= MAX_BUFFER then POINTER = 0

    BUFFER (POINTER) = DATA

end if

return

end procedure

Note the global variables are used by the READ_DATA and
INITIALISE_BUFFER subroutines.

Andrew Swallow
Received on Thu Sep 29 21:42:09 2005