Re: [Lit.] Buffer overruns

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

Date: Sat, 01 Jan 2005 12:57:43 +0100

Douglas A. Gwyn wrote:

> David Wagner wrote:
>
>> Ok, ok, let me anticipate one potential response. Maybe you are
>> thinking:
>> "I'd much rather be sure I'll both get to the supermarket *and* live".
>> But this is often not an option.
>
>
> Then I think I'd move to where it was much safer to
> go to the supermarket!

Mmm, if you have much money, you could also employ someone
to do the purchase for you and let him risk his life just
in case ;-)

>
>> ... Sometimes there is no way
>> to ensure that both goals will be met, and then you have to consider
>> which goal is more important and build your system appropriately.
>
>
> This isn't about trade-offs, it about mistaking loss
> of correctness in the *primary design* for some
> incidental unforeseeable spurious random error. Since
> buffer overruns are foreseeable and, in an attack
> context not spurious nor random, the assumed error
> model is inapplicable. If you want to put effort into
> stopping such attacks, then allowing the flaws to
> exist and trying to deal with the consequences is far
> inferior to making sure that the flaws do not exist.
> The former allows a perpetual denial of service, for
> example, while the latter achieves its main function
> despite attack attempts.
>
> Air bags are helpful, but the main reason they were
> mandated was that drivers refused to take the trouble
> to use their existing safety harnesses.

What is your 'model' against hackers exploiting buffer
overruns? What do you do for that in your code? (Do you
know all the tricks that they could perform in the future?)
Cf. a recent post of Wagner.

M. K. Shen

Relevant Pages

  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >> Why do we need to know whether our development methodology is good ... >> to eliminate all buffer overruns? ... >> an attack that we think probably is unlikely to be feasible (maybe it ... > But above you agreed that temporarily ignoring errant reads would not be ...
    (sci.crypt)
  • Re: firewall: black or white...
    ... > interresting systems to play with. ... > If someone is looking for a system to attack, ... almost every security plan incorporates similar flaws. ...
    (comp.os.linux.security)
  • Re: Enabling telnet, ftp, pop3 for root...
    ... If you make it so NOBODY can attack it then NOBODY can ... Any system can contain flaws. ... security flaws, the system with less security flaws is more secure. ...
    (alt.os.linux)
  • Re: [Lit.] Buffer overruns
    ... incidental unforeseeable spurious random error. ... inferior to making sure that the flaws do not exist. ... despite attack attempts. ...
    (sci.crypt)