Re: [Lit.] Buffer overruns

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 01/15/05 

Date: Sat, 15 Jan 2005 01:08:19 +0100

Douglas A. Gwyn wrote:
> Mok-Kong Shen wrote:
>
>> The practically more serious case is in my view not
>> that the programmers have not sufficiently catered for
>> normal cases of bound excess (which presumably could be
>> mostly comparatively easily prevented from occuring) but
>> rather 'intentional' creation of such disasters by
>> hackers. I am not aware of your having given concrete
>> recipes of dealing with that for a languate like C in
>> this thread. (If I am wrong, please cut and paste
>> something.) Note BTW that neither programmers nor
>> training and management etc. could be 'perfect'.
>
>
> I don't know why you keep harping on imperfection
> of components when the goal is a nearly perfect
> system, and proper software engineering processes
> achieve the latter despite the former. Errors
> get caught and corrected as early in the software
> development cycle as possible, so that they don't
> persist into the product's run time execution.
>
> I don't give "recipes" because it is a big subject
> well covered in standard texts, and furthermore
> requires understanding, not just following recipes.
>
> If the product is correct then hackers have no
> opening to exploit. A program that doesn't allow
> buffers to be overrun in the first place will not
> allow hackers to exploit buffer overrun.

I said many times that this is defining a problem
away. Analogy: One can define a perfectly healthy man.
He will certainly never need the care of a doctor. So,
if there are people who get sick, just say to them to
try to 'become' a perfectly healthy person. Does that
solve the 'real' problem?? The fact IS that lots of
software products ARE not correct, or else there wouldn't
be the blames for e.g. certain MS products. Now do you
think that 'something' has to be done to deal with the
real-world issue of continued production of non-perfect
(incorrect) software? (If yes, then cf. what I wrote in
earlier posts.)

M. K. Shen

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... Note BTW that neither programmers nor ... I don't give "recipes" because it is a big subject ... If the product is correct then hackers have no ... allow hackers to exploit buffer overrun. ...
    (sci.crypt)
  • Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
    ... > I think he's referring to the reinvention of execute protection, ... > was loaded onto the stack by exploiting a buffer overrun. ... > doesn't make the app correct by any means, ... Programmers have consistantly demonstrated that they cannot be trusted with ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... buffer overrun is by definition bounds being ... > There is no reason for an algorithm to ever attempt ... Note BTW that neither programmers nor ...
    (sci.crypt)
  • Re: C is best
    ... Most hackers are just ... There is a reason poor programmers and designers are called "hackers". ... There is no broadly accepted definition of the word ... avoid are the kind of people that avoid your kind of people. ...
    (comp.lang.c)
  • Re: C is best
    ... William Hughes writes: ... profundity of thought that it deserved, and I think I succeeded admirably. ... hackers are almost never the best programmers. ...
    (comp.lang.c)